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PREFACE 



MANUAL OBJECTIVES 

The goal of this manual is to provide information necessary to prepare 
a conventional I/O driver for RSX-11M and subsequently incorporate it 
into an operational user-tailored system. A "conventional" driver is 
best explained by example. Disks and unit record devices are 
considered conventional; the LPS-11, UDC-11, and TM11 are considered 
unconventional. Complexity of device servicing requirements sets the 
dividing line, which is not easily established in black-and-white 
terms. 



INTENDED AUDIENCE 

The manual assumes that you understand the device for which you are 
writing a driver, and that you are familiar with the PDP-11 processor, 
its peripheral devices, and the software supplied with an RSX-11M 
system. Although this manual is organized tutorially, the intended 
audience is assumed to be at a system programmer level of expertise; 
thus, the manual does not contain definitions of data processing terms 
and concepts familiar to senior-level professionals. 



STRUCTURE OF THIS DOCUMENT 

This document proceeds from chapter to chapter toward increasingly 
detailed levels of implementation. 

Chapter 1 is a general introduction to I/O drivers in the RSX-11M 
system. 

Chapter 2 is a functional description of the RSX-11M device-level I/C 
system. It discusses both data structure and code requirements. 

Chapter 3 details how to incorporate a user-written driver into the 
system. 

Together, Chapters 1, 2, and 3 provide a complete description of the 
requirements that must be met in creating a system that contains a 
user-written driver. 

Chapter 4 provides programming-level details on I/O data structures 
and on drivers that service several controllers. 

Chapter 5 discusses all the I/Q-related Executive services. 

Chapter 6 gives two examples of user-written drivers. 

Appendix A describes the address doubleword. 
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Appendix B outlines special considerations for extended memory NPR 
device drivers. 

Appendix C lists system macros that supply symbolic offsets for system 
data structures. 

Appendix D is a guide for the user in developing an Ancillary Control 
Processor (ACP) . 



ASSOCIATED DOCUMENTS 

Familiarity with the system implies an in-depth exposure to the 
following manuals: 

• RSX-11M System Generation and Installation Guide 

• RSX-11M/M-PLUS I/O Drivers Reference Manual 

• RSX-11M/M-PLUS Executive Reference Manual 

• RSX-11M/M-PLUS Utilities Manual 

• IAS/RSX-11 I/O Operations Reference Manual 

As adjuncts to this manual, you are advised to study existing I/O 
drivers. The RL-11 disk driver is a good example of an NPR device and 
the TA-11 (cassette) is illustrative of a programmed I/O device. In 
addition, a perusal of Executive source code contained in the files 
IOSUB, SYSXT, DRQIO, BFCTL, and DRDSP (stored in UFD [11,10] on the 
Executive source disk) is recommended. 

Other manuals closely allied to the purposes of this document are 
described briefly in the RSX-11M/RSX-11S Information Directory and 
Index . The Information Directory defines the intended readership of 
each manual in the RSX-11M/RSX-11S set and provides a brief synopsis 
of each manual's contents. 
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SUMMARY OF TECHNICAL CHANGES 



This revision of the RSX-11M Guide to Writing an I/O Driver 
incorporates the following technical changes and additions: 

1. Tables have been added to aid the user in establishing I/O 
function bit masks for disk drives, magtape drives, and unit 
record devices (see Tables 4-3, 4-4, and 4-5). 

2. Error logging offsets have been added to the SCB and UCB. 
See the descriptions of the SCB and the UCB in Chapter 4. 

3. Other additions have been made to various UCB offsets: 

• New symbolic name U.MUP has been added (redefinition of 
U.CLI; see Chapter 4). 

• Symbolic names for magtape density bit masks have been 
added to the description of U.CW3 (see Chapter 4). 

• The DV.MBC offset to U.CW1 has been renamed to DV. EXT (see 
Chapter 4) . 

4. Some Executive routines listed in Chapter 5 have been moved 
to new Executive modules. The following is a list of the 
affected modules and subroutines: 

Routine Old Module New Module 

$ACHKB/$ACHCK IOSUB EXESB 

$ASUMR IOSUB MEMAP 

$DEUMR IOSUB MEMAP 

$DVMSG IOSUB EXESB 

$MPUBM IOSUB MEMAP 

$MPUB1 IOSUB MEMAP 

$RELOC IOSUB MEMAP 

$STMAP IOSUB MEMAP 

$STMP1 IOSUB MEMAP 

In addition, the inputs to $MPUB1 have been modified (see 
Chapter 5) . 

5. Three additional routines have been documented in Chapter 5: 

$EXRQP, $QRMVF, and $SWSTK. 

6. An appendix intended to aid the user in writing an Ancillary 
Control Processor (ACP) has been added (see Appendix D) . 
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CHAPTER 1 
INTRODUCTION TO I/O DRIVERS 



The software supplied by DIGITAL for an RSX-11M system includes I/O 
drivers for a number of standard I/O devices. An I/O driver is a part 
of the RSX-11M Executive that services one type of I/O device. A 
driver may handle one or several controllers, each with one or several 
device-units attached. 



1.1 RESIDENT AND LOADABLE DRIVERS 

A driver can be resident or loadable. A resident driver is a 
permanent part of the Executive, incorporated at system generation. A 
loadable driver, while also part of the Executive, can be added to or 
unloaded from a system almost at will by means of MCR or VMR commands. 
During the system generation dialog, you can specify that you want 
this facility. 

Making drivers loadable can result in less Executive code, and thus 
permits an increase in available dynamic storage region (pool) space 
or increased space for user tasks. You can unload from the system any 
driver that is not needed for a period of time. For example, assume 
your system has both a paper tape reader and a card reader. If only 
one of them is connected to the system at any one time, you could load 
the driver for the on-line device and unload the other driver, thus 
reducing the size of the Executive. 

A loadable user-written driver is easier to incorporate into a system 
and easier to debug than a resident one. You can incorporate a 
resident driver into a system only during system generation; the 
Executive must be rebuilt and the system bootstrapped each time it is 
incorporated after debugging. In contrast, you can incorporate a 
loadable driver into a system with a single MCR command. 
Incorporating and debugging user-written drivers are discussed in 
Chapter 3. 
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INTRODUCTION TO I/O DRIVERS 

1. 2 FUNCTION OF AN I/O DRIVER 

An I/O driver is an asynchronous process (not a task) that calls and 
is called by the Executive to service an external I/O device or 
devices. The role of an I/O driver in the RSX-11M I/O structure is 
specific and limited. A driver performs the following functions: 

• Receives and services interrupts from its I/O device (s) 

• Initiates I/O operations when requested to do so by the 
Executive 

• Cancels in-progress I/O operations 

• Performs other (device-specific) functions upon power failure 
and device time-out 

As an integral part of the Executive, a driver possesses its own 
context, allows or disallows interrupts, and synchronizes its access 
to shared data bases with that of other Executive processes. It may 
also synchronize with itself: A driver can handle several device 
controllers (each with several device-units) all operating in 
parallel. A user-written driver must adhere to RSX-11M programming 
conventions in order to ensure the integrity of the Executive. 
Section 2.5 and Chapter 4 discuss these conventions. 
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CHAPTER 2 
THE RSX-11M I/O SYSTEM—PHILOSOPHY AND STRUCTURE 



2.1 I/O PHILOSOPHY 

Memory constraints and compatibility requirements dominated the design 
philosophy and strategy used in creating RSX-llM. To meet its 
performance and space goals, the RSX-llM I/O system attempts to 
centralize common functions, thus eliminating the inclusion _ of 
repetitive code in each and every driver in the system. To achieve 
this centralization, a substantial effort has been expended in 
designing the RSX-llM data structures, which are used to drive the 
centralized routines. The effect is to reduce substantially the size 
of individual I/O drivers. The table structures require space and 
must be considered with the total size of the I/O system. 
Nevertheless, the size reduction effected by centralizing functions, 
combined with table-driven design, enables RSX-llM to meet its 
intended memory and performance goals. 



2.2 STRUCTURE 

The following sections: 

1. Place an I/O driver in the context of the overall RSX-llM I/O 
system 

2. Establish the responsibilities of an I/O driver 

3. Functionally describe the driver's interface to the Executive 
subroutines and the I/O data structures 



2.2.1 I/O Hierarchy 

The RSX-llM I/O system is structured as a loose hierarchy. The term 
"loose" indicates that you can enter the hierarchy at any of its 
levels; this characteristic is contrasted to "tight" hierarchies that 
permit entry only from the top level. Tight hierarchies exist 
principally for security and protection, but consume equipment 
resources. Figure 2-1 shows the loose RSX-llM I/O system hierarchy. 
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THE RSX-iiM I/O SYSTEM — PHILOSOPHY AND STRUCTURE 



2.2.1.1 PCS/RMS - At the top of the hierarchy are File Control 
Services (FCS) and Record Management Services (RMS), which provide 
device-independent access to devices included in a given system 
configuration. The user task has two levels with which to interface 
with FCS or RMS: Get/Put and Read/Write. Get/Put facilitates the 
movement of data records, whereas Read/Write provides a more basic 
level of access affording more direct control over data movement 
between a task and peripheral devices. 
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Figure 2-1 I/O Control Flow 



The discussion of FCS and RMS is brief because their existence is 
completely transparent to the driver and rarely concerns the writer of 
a conventional driver. FCS or RMS accepts a user request, interprets 
it, and translates it into a series of low-level system directives 
known as QIOs. 



2.2.1.2 QIO - The QIO directive is the lowest level of task I/O. Any 
task can issue a QIO directive which allows direct control over 
devices that are connected to a system and that have an I/O driver. 
The QIO directive forces all I/O requests from user tasks to go 
through the Executive. The Executive works to prevent tasks from 
destructively interfering with each other and with the Executive 
itself. 
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THE RSX-11M I/O SYSTEM — PHILOSOPHY AND STRUCTURE 

2.2.1.3 Executive I/O Processing - The Executive processes I/O 
requests using the following: 

1. An Ancillary Control Processor (ACP) 

2. A collection of Executive components consisting of: 

a. QIO directive processing 

b. I/O-related subroutines 

c. The I/O drivers 

An ACP is responsible for maintaining the structure and integrity of 
data stored on file-structured volumes. It maps virtual I/O functions 
to logical I/O functions, and makes volume-protection checks. The 
driver converts a logical block number into a physical address on a 
file-structured device. No direct connection normally exists between 
the ACP and a driver. 

An ACP is a privileged task, and requires a partition in which to 
execute. Drivers, on the other hand, are specialized system 
processes, not tasks. 

The Executive provides QIO directive processing. It also provides a 
collection of subroutines that are used by drivers to obtain I/O 
requests, to facilitate interrupt handling, and to return directive 
status codes. Actual control of the device is performed by the 
driver. These subroutines are examined in detail in Chapter 5. 
Executive subroutine services and QIO directive processing are shown 
as distinct components but are, in fact, both part of the Executive. 
These subroutines centralize common driver functions, thus eliminating 
duplicate code sequences among drivers. 



2.2.2 Role of I/O Driver in RSX-11M 

Every I/O driver in the RSX-11M system has the following five entry 
points: 

• Device interrupt^- 

• I/O initiator 

• Device time-out 

• Cancel I/O 

• Power failure 

The first entry point is entered by a hardware interrupt; the other 
four are entered by calls from the Executive. Functional details 
regarding these entry points follow. 



1. A device may trigger more than one distinct interrupt entry. For 
example, a full-duplex device would have two. 
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THE RSX-11M I/O SYSTEM — PHILOSOPHY AND STRUCTURE 

2.2.2.1 Device Interrupt - Control passes to this entry point when a 
device previously initiated by the driver completes an I/O operation 
and causes an interrupt in the central processor. The connection 
between the device and the driver in this instance is direct; the 
Executive is not involved. 



2.2.2.2 I/O Initiator - The Executive calls this entry point to 
inform the driver that work for it is waiting to be done. In effect, 
this is a wake-up signal for the driver. 



2.2.2.3 Device Time-out - When a driver initiates an I/O operation, 
it can establish a time-out count. If the function then fails to 
complete within the specified time interval, the Executive notes the 
time lapse and calls the driver at this entry point. 



2.2]. 2.4 Cancel I/O -A number of circumstances arise within the 
system that require a driver to terminate an in-progress I/O 
operation. When such a termination becomes necessary, a task so 
informs the Executive, which then relays the request to the driver by 
calling it at the cancel I/O entry point. 



2.2.2.5 Power Failure - The Executive calls the driver's power- 
failure entry point in three different circumstances: 

• When power is restored after a failure 

• When the system is bootstrapped 

• When the driver is loaded (if it is a loadable, as opposed to 
a resident, driver) 

Power Restore - Two conditions can initiate a call to the driver when 
power is restored following a power failure. First, the Executive 
automatically calls the power-failure entry point when power is 
restored any time the controller is busy (that is, when I/O is in 
progress). Second, a driver has the option to be called regardless of 
the existence of an outstanding I/O operation at the time the power is 
restored (See the description of the UC.PWF bit symbol in Section 
4.1.4.1). Frequently, a driver's response to a power failure or to an 
I/O failure is identical to that when its device times out; in such a 
case, the power-failure entry point may simply be a RETURN 
instruction, because the driver will recover eventually via the 
time-out entry point. 

Bootstrap - When the system is bootstrapped, a power-failure interrupt 
is simulated. This simulation gives drivers the opportunity to carry 
out any appropriate preoperational initialization. 

Load - The MCR LOA command calls a loadable driver at its 
power-failure entry point if the device is on line and UC.PWF is set 
(see Section 4.1.4.1). 
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THE RSX-11M I/O SYSTEM — PHILOSOPHY AND STRUCTURE 

2.2.2.6 Summary — Role of an I/O Driver - Functionally, a driver in 
RSX-11M is responsible for: 

• Servicing device interrupts 

• Initiating I/O operations 

• Cancelling in-progress I/O operations 

• Performing device-related functions when a time-out or power 
failure occurs 

A driver exists as an integral part of the Executive; it can call, 
and be called by, the Executive. The driver initiates device I/O 
operations directly and receives device interrupts directly. All 
other entry points are entered by means of Executive calls. A driver 
never receives a QIO request directly, and has no direct interaction 
with the ACP. 



2.3 DATA STRUCTURES 

An I/O driver interacts with the following data structures: 

• Device Control Blocks (DCBs) 

• Unit Control Blocks (UCBs) 

• Status Control Blocks (SCBs) 

• The I/O packet 

• The I/O queue 

• The fork list 

• Device interrupt vector 

The first four of these data structures are especially important to 
the driver, because it is by means of these data structures that all 
I/O operations are effected. They also serve as communication and 
coordination vehicles between the Executive and individual drivers. 

The I/O queue and the fork list are actually Executive data 
structures, but are discussed here to illustrate all facets of the 
interaction of an I/O driver with the Executive. The I/O queue is a 
list of I/O packets built by the QIO directive, principally from 
information in the caller's Directive Parameter Block (DPB) . The fork 
list synchronizes access to shared Executive data structures. 

Entry to a driver following a device interrupt is accomplished through 
the appropriate hardware device interrupt vector. As will be seen, 
writers of resident drivers are responsible for properly initializing 
this vector. It is discussed in conjunction with the data structures 
associated with a driver. 
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2.3.1 The Device Control Block (DCB) 

At least one DCB exists for each type of device appearing in a system 
(device type should not be equated with device-unit) . The function of 
the DCB is to describe the static characteristics (rather than 
execution-time information) of both the device controller and the 
units attached to the controller. All the DCBs in a system form a 
forward-linked list, with the last DCB having a link of zero. Most of 
the data in the DCB is established in the assembly source for the 
driver data structure. The DCB is used by the QIO directive 
processing code in the Executive and not by the driver. 



2.3.2 The Unit Control Block (UCB) 

One UCB exists for each device-unit attached to a system. Much of the 
information in the UCB is static, though a few dynamic parameters 
exist. 1 For example, the redirect pointer, which reflects the results 
of the MCR RED command is updated dynamically. As with the DCB, most 
of the UCB is established in the assembly source; however, its 
contents are used and modified by both the Executive and the driver. 
Usually, either the Executive or the driver — but not both — modify 
a datum. 



2.3.3 The Status Control Block (SCB) 

One SCB exists for each device controller in the system. This is true 
even if the controller handles more than one device-unit (like the 
RLllController) . Line multiplexers such as the DH11 and DJ11 are 
considered to have one controller for each line because all lines can 
transfer in parallel. Most of the information in the SCB is dynamic. 
Both the Executive and the driver use the SCB. 



2.3.3.1 Interrelation of the I/O Control Blocks -This section 
discusses the interrelationship among the DCB, UCB, and SCB without 
entering into the detailed contents of the control blocks, which are 
discussed in Chapter 4. 

Figure 2-2 shows the data structure that would result for three LA36 
DECwriters interfaced by means of a DH11 multiplexer. The structure 
requires one DCB, three UCBs , and three SCBs, because the activity on 
all three units can proceed in parallel. 

Figure 2-3 depicts the internal data structure for an RK11 disk 
controller with three units attached. Note that only one SCB exists, 
because only one of the three units can be active at any given time. 



1. From the UCB, however, it is possible to access most of the othf>r 
structures in the I/O data base (see Figure 2-5). In this sense the 
UCB gives access to a large amount of dynamic data. 
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Figure 2-4 shows the data structure for two RK11 disk controllers, 
each of which has two drives attached. Here there are two SCBs , 
because both of the disk controllers can operate in parallel. 

Taken together. Figures 2-2, 2-3, and 2-4 illustrate the strategy 
underlying the existence of three basic I/O control blocks. There 
need be only one DCB for each device type. There may be one or more 
SCBs, depending on the degree of parallelism that is desired or 
possible: one for each device-unit, or one for each controller 
servicing several device-units. The number of UCBs and SCBs, and 
their interrelationships, are uniquely determined by the hardware 
these data structures describe. 

This data structure provides considerable flexibility in configuring 
I/O devices, and, because of the information density in the structures 
themselves, substantially reduces the code requirements of the 
associated drivers. 







Figure 2-2 DH11 Terminal I/O Data Structure 
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Figure 2-3 RK11 Disk I/O Data Structure 




Figure 2-4 I/O Data Structure for Two RK11 Disk Controllers 



2. 3. 4 The I/O Packet 

An I/O packet contains information extracted from the QIO DPB, as well 
as other information needed to initiate and terminate I/O requests. 
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2.3.5 The I/O Queue 

Each time a task makes an I/O request, the Executive performs a series 
of validity checks on the DPB parameters. If these checks prove 
successful, the Executive generates a data structure called an I/O 
packet. The Executive then inserts the packet into a device-specific, 
priority-ordered list of packets called the I/O queue. Each I/O 
queue's listhead is located in the SCB to which the I/O requests 
apply. 

When a device driver needs work, it requests the Executive to dequeue 
the next I/O packet and deliver it to the requesting driver. 
Normally, the driver does not directly manipulate the I/O queue. 1 



2.3.6 The Fork List 

The fork list is a mechanism by which RSX-llM splits off processes 
that require access to shared data bases, or that require more CPU 
time to process an interrupt than is compatible with fast, real-time 
response of the overall system. 

A process that calls $FORK requests the Executive to transform it into 
a "fork process" and place it on the fork list. What this means is 
that a call to $FORK saves a "snapshot" of the process (registers R4, 
R5, and the PC) in a fork block. This fork block is queued on the 
fork list in first-in-first-out (FIFO) order. 

When a fork process has worked its way to the front of the fork list, 
R4 and R5 are restored and execution restarts at the statement after 
CALL $FORK. The process is unaware that a pause of indeterminate 
length has occurred. 

A fork process exists in a status intermediate between an interrupting 
routine and an ordinary task requesting system resources. Routines in 
the system stack — requests for interrupt processing — are run first. 
They can be interrupted only by higher-priority requests. Routines in 
the fork list are run when the system stack is empty — that is, they 
are completely interruptable. Finally, other tasks are run only when 
both the system stack and the fork list are empty. 

Driver interrupts are processed at priority 7 and are thus 
noninterruptable. By system convention, no process should run in a 
noninterruptable mode for more than 100 microseconds. This convention 
ensures prompt attention to interrupting real-time events. 

In practice, drivers servicing interrupts drop from priority 7 to a 
lower priority (namely, that of the interrupting source) after issuing 
a few instructions. Another system convention states that processing 



1. An exception is the case in which a driver needs to examine an I/O 

packet before it is queued, or in place of having it queued. For the 

driver to accomplish this examination, you must set the bit UC.QUE in 
the control byte (U.CTL) of the UCB (described in Section 4.1.4). 

The most common reason for a driver to examine a packet before queuing 
is that the driver employs a special user buffer, other than the 

T-»^v-maT knf for iica/^ ■? i-. =s f r^nefov vomioef- Wi fhin +- Vl a r«ftnf flvf r* € f ho 

requesting task, the driver must address-check and relocate such a 
special buffer. See Section 6.3 for an example of a driver that does 
this. 



2-9 



THE RSX-11M I/O SYSTEM — PHILOSOPHY AND STRUCTURE 

at this partially interruptable level should not exceed 500 
microseconds. Often, more time than this is required to process an 
interrupt. The fork list mechanism provides a secondary interrupt 
stack whose members are processed first-in-first-out whenever the 
system stack is empty. 

A process can also call $FORK to access a shared data base — a system 
table, for example. You must strictly control such access in order to 
avoid conflicts. Under RSX-11M, many drivers can run in parallel; a 
multicontroller driver can run in parallel with itself. In these 
circumstances access to common data bases must be controlled. 

Of the two available methods of controlling such access — interrupt 
lockout and priority queuing — RSX-11M uses priority queuing. The fork 
list is the queue of requests for such access. Fork processes are 
granted FIFO access to common data bases. Once granted such access, a 
process is guaranteed control of the data base until it exits. 



2.3.7 The Device Interrupt Vector 

The device interrupt vector consists of two consecutive words giving 
the address of the interrupt-service routine and the priority at which 
it is to run (always set to PR7) . The low four bits of the second 
word of the interrupt vector must contain the number of the controller 
that interrupts through the vector. This requirement enables a driver 
to service several controllers with few code changes (see Sections 4.2 
and 4.3 for an example and discussion of multicontroller driver 
coding) . Generally, these bits are set to 0. 



2.4 EXECUTIVE SERVICES 

The Executive provides services related to I/O drivers that can be 
categorized as pre- and post-driver initiation. The preinitiation 
services are those performed by the Executive during its processing of 
a QIO directive; these services are not available as Executive calls. 

The goal of pre-driver initiation processing is to extract from the 
QIO directive all I/O support functions not directly related to the 
actual issuance of a function request to a device. If the outcome of 
pre-driver initiation processing does not result in the queuing of an 
I/O packet to a driver, the driver is unaware that a QIO directive was 
issued. Many QIO directives do not result in the initiation of an I/O 
operation. 

The post initiation services are those available to the driver after 
it has been given control, either by the Executive or as the result of 
an interrupt. They are available as needed by means of Executive 
calls. 

An important concept used in this section and in Section 2.5 is the 

"state" of a process. In RSX-11M, a process can run in one of two 

states: user or system. Drivers operate almost entirely in the 

system state; the programming standards described in Section 2.5 
apply to system-state processes. 
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2.4.1 Pre-Driver Initiation Processing 

In processing a QIO directive, the Executive module DRQIO performs the 
following pre-driver initiation services: 

1. Checks to verify whether the supplied logical unit number 
(LUN) is legal. If not, the directive is rejected. 

2. If the LUN is valid, checks to verify whether a valid UCB 
pointer exists in the Logical Unit Table (LUT) for the 
specified LUN. This test determines if the LUN is assigned. 
If the test fails, the directive is rejected. 

3. If steps 1 and 2 are successful, traces down the redirect 
chain to locate the correct UCB to which the I/O operation 
will actually be directed. 

4. Checks the event flag number (EFN) and the address of the I/O 
Status Block (IOSB) . If either is illegal, the directive" is 
rejected. Immediately following validation, the Executive 
resets the subject event flag and clears the IOSB. 

5. Obtains 18 words of dynamic storage and builds the 
device-independent portion of an I/O packet. 

If steps 1 through 5 succeed, the Executive sets the 
directive status to +1. 

Note that directive rejections in any of the above steps are 
completely transparent to the driver. Such rejections cause 
a return of carry bit set. 

6. Checks the validity of the function being requested and, if 
appropriate, checks the buffer address, byte count, and 
alignment requirements for the specified device. 

If any of these checks fails, the Executive calls the I/O 
Finish routine ($IOFIN) . $IOFIN sets the I/O status and 
clears the QIO request from the system. 

7. If the requested function does not require a call to the 
driver, the Executive takes the appropriate actions and calls 
$IOFIN. 

8. If all I/O packet checks are positive, the Executive places 
the I/O packet in the driver queue according to the priority 
of the requesting task, or gives the packet to the driver (if 
bit UC.QUE is set — see Section 4.1.4.1). 



2.4.2 Post-Driver Initiation Services 

Once a driver is given control following an I/O interrupt or by the 

Executive itself, a number of Executive services are available to the 

driver. These services are discussed in detail in Chapter 5. 
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However, four Executive services merit special emphasis because 
virtually every driver in the system uses them: 

• Interrupt Save ($INTSV) 

• Get Packet ($GTPKT) 

• Create Fork Process ($FORK) 

• I/O Done ($IODON or $IOALT) 



2.4.2.1 Interrupt Save ($INTSV) 1 - Interrupts from a device are 
fielded by the driver. Immediately following the interrupt, the 
driver operates at hardware priority level 7 and is, therefore, 
noninterruptable. If the driver needs a lengthy processing cycle 
(greater than 100 microseconds) to process the interrupt, or if it 
requires the use of any general-purpose registers, it calls $INTSV. 
This call queues external interrupts, alters the hardware priority, 
and provides the calling routine with two free registers to use in 
processing the interrupt. $INTSV is discussed in more detail in 
Section 2.5. 



2.4.2.2 Get Packet ($GTPKT) - The Executive, after it has queued an 
I/O packet, calls the appropriate driver at its I/O-initiatori entry 
point. The driver then immediately calls the Executive routine $GTPKT 
to obtain work. 2 if work is available, $GTPKT delivers to the driver 
the highest-priority, executable I/O packet in the driver's I/O queue, 
and sets the SCB status to "busy." If the driver's I/O queue is empty, 
$GTPKT returns a no-work indication. If the SCB related to the device 
is already busy, $GTPKT so informs the driver, and the driver 
immediately returns control to the Executive. 

Note that, from the driver's point of view, no distinction exists 
between no-work and SCB busy, because an I/O operation cannot be 
initiated in either case. 



2.4.2.3 Create Fork Process ($FORK) - You can synchronize access to 
shared data bases by creating a fork process. When a driver needs to 
access a shared data base, it must do so as a fork process; the 
driver becomes a fork process by calling $F0RK. The SCB contains 
preallocated storage for a 4- or 5-word "fork block." See Section 
4.1.3.1 for a description of the fork block. Section 5.3 contains 
details on $F0RK. 



1. A loadable driver on a mapped system cannot call $INTSV directly. 
See Section 4. 3. 

2. An exception is a driver that handles special user buffers. Such a 
driver must call certain other Executive routines before calling 
$GTPKT. See Section 6.3 for an example. 
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An interrupt routine cannot call $FORK directly; the routine must 
first switch to system state by using the INTSV$ macro or calling 
$INTSV (as described in Section 2.4.2.1). Furthermore, the 
interrupting routine's priority is lowered to that of the requesting 
source. 

After calling $FORK, a routine is fully interruptable (priority 0) , 
and its access to shared system data bases is strictly linear. 



2.4.2.4 I/O Done ($IODON or $I0ALT) - At the completion of an I/O 
request, the subroutines $IODON or $I0ALT perform a number of 
centralized checks and additional functions: 

• Store status if an IOSB address was specified 

• Set an event flag, if one was requested 

• Determine if a checkpoint request can now be honored 

• Determine if an AST should be queued 

$IODON and $IOALT also declare a significant event, reset the SCB and 
device unit status to "idle," and release the dynamic storage used by 
the completed I/O operation. 



2.5 PROGRAMMING STANDARDS 

RSX-11M I/O drivers function as integral components of the RSX-11M 
Executive. They must follow the same conventions and protocol as the 
Executive itself if they are to avoid complete disruption of system 
service. This manual has been written to enable you to incorporate 
I/O drivers into your system. Failing to observe the internal 
conventions and protocol can result in poor service and a reduction in 
system efficiency. 



2.5.1 Process-Like Characteristics of a Driver 

A driver is an asynchronous Executive process. As a process, it 
possesses its own context, allows or disallows interrupts, and 
synchronizes functions within itself (all drivers can be parallel, 
multiunit, multicontroller) and with other Executive processes 
executing in parallel. 

Most RSX-11M drivers are small. Their small size is made possible by 
a comprehensive complement of centralized services available by calls 
to the Executive, and by the availability of an information-dense, 
highly formalized I/O data structure. 



2.5.2 Programming Conventions 

Appendix E of the PDP-11 MACRO-11 Language Reference Manual describes 
program coding standards. DIGITAL recommends that users refer to 
these standards to assist in preparing standards for their own 
installations. 
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2.5.3 Programming Protocol 

Because an I/O driver accepts interrupts directly from the devices it 
controls, the central Executive relies on the driver to follow strict 
programming protocol so that system performance is not degraded. 
Furthermore, the protocol ensures that the driver properly distributes 
shared resources according to user-specified priorities, The protocol 
is summarized in Section 2.5.3.4. 

When a device interrupts, an I/O driver is entered. The driver 
usually calls $INTSV or issues the INTSV$ macrol for common save and 
state-switching services. At the completion of the services provided 
by INTSV$ or $INTSV, the interrupt routine is again given control to 
complete the interrupt service. The exit routine $INTXT restores the 
state prior to switching to the system state, controls the unnesting 
of interrupts, and makes checks on the state of the system (for 
example, it checks to determine whether it is necessary to switch 
stacks) . The fork processor causes access to shared system data bases 
to be linear. The details of all these routines are given in Chapter 
5. 

The interrupt vectors for each controller type in low memory contain a 
program counter (PC) unique to each interrupting source and a 
Processor Status Word (PSW) set with a priority of 7. It is a system 
software convention to use the low-order four bits of the PSW to 
encode the controller number for multicontroller drivers. When a 
device interrupt occurs, the hardware pushes the current PSW and PC 
onto the current stack and loads the new PC and PSW (set at priority 7 
with the controller number in the condition-code bits) from the 
appropriate interrupt vector. The driver then starts executing with 
interrupts locked out. A driver itself may be executing at one of 
three levels of interrupt sensitivity: 

1. At priority 7 with interrupts locked out. 

2. At the priority of the interrupting source; thus, interrupt 
levels greater than the priority of the interrupting source 
are permitted. 

3. At fork level, which is at priority 0. 



2.5.3.1 Processing at Priority 7 with Interrupts Locked Out - By 

internal convention, processing at this level is limited to 100 
microseconds. If processing can be completed in this time, either 
without using general-purpose registers or by saving and restoring the 
registers used, then the driver simply dismisses the interrupt by 
executing an RTI instruction. The interrupt is processed and 
dismissed with minimal overhead. 



2.5.3.2 Processing at the Priority of the Interrupting Source - If 

the driver requires additional processing time or requires the use of 
general-purpose registers, it calls the $INTSV routine. Loadable 
drivers on mapped systems must use the INTSV$ macro. All other 
drivers can use the INTSV$ macro or call the $INTSV routine directly. 
The priority at which the caller is to run is included in the call to 
the $INTSV routine. The driver sets this priority level to that of 
the interrupting source. 



1. The system macro INTSV$ simplifies the coding of standard 
interrupt-entry processing (see Section 4.3). 
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The $INTSV routine sets up the interrupt routine so that it can be 

interrupted by devices with priorities higher than that of the 

interrupting source, and switches to system state if the processor is 
not already in system state. 

The $INTSV routine also saves registers R4 and R5 to free these 
registers for the driver. (A standard practice is for the driver to 
set R4 to the address of the interrupting device's SCB, and R5 to its 
UCB address.) An internal programming convention assumes that the 
driver will not require more than these two registers during interrupt 
processing. If it does, the driver must save and restore any 
additional registers it uses. Processing time following the return 
from the $INTSV routine should not exceed 500 microseconds. 1 



NOTE 

In actual practice, every driver in the 
system calls the $INTSV routine on every 
interrupt, due to three factors: 

1. It is difficult to service an 
interrupt without using one or two 
registers. 

2. Most interrupt code can safely be 
executed at the priority of the 
interrupting source. Executing at 
that priority is more desirable in 
terms of system response than 
continuing to execute at the highest 
priority. 

3. The $INTSV routine is an integral 
part of the interrupt mechanism for 
loadable drivers. 



2.5.3.3 Processing at Fork Level - A driver calls $FORK to become 
fully interruptable (so that it conforms to the 500-microsecond time 
limit), or to access the shared system data base. The INTSV$ macro 
must be issued or the $INTSV routine must be called prior to calling 
$F0RK. 

By calling $FORK, the routine becomes fully interruptable and its 

access to system data bases is strictly linear. At fork level, all 

registers are available to the process, and R4 and R5 retain the 
contents they had on entrance to $F0RK. 



1. The 500-microsecond period is a guideline. The longer the period 
of time a real-time executive spends at an elevated priority level, 
the less responsive is the system to devices of equal or lower 

fj. j. VI. J. b j • + f.z j. *j ^uo.uv.,1. J.llt J..J e^3^-e^J.t*J.J.J^ J. 1U£SV^ L L.QUU J.J- LUC UtV 1V-C fJClil^ 

serviced is at the same or higher priority than a character-interrupt 
device such as the DU11, which is vulnerable to data loss due to 
interrupt lockout. 

2-15 



THE RSX-11M I/O SYSTEM — PHILOSOPHY AND STRUCTURE 

2.5.3.4 Programming Protocol Summary - Drivers are required to adhere 
to the following internal conventions when processing device 
interrupts: 

1. No registers are available for use unless $INTSV has been 
called or the driver explicitly performs save and restore 
operations. If $INTSV is called, registers R4 and R5 are 
available; any other registers must be saved and restored. 

2. Noninterruptable processing must not exceed twenty 
instructions, and processing at the priority of the 
interrupting source must not exceed 500 microseconds. 

3. You must use a fork process for all modifications to system 
data bases. 



2.6 FLOW OF AN I/O REQUEST 

Following an I/O request through the system at the functional level 
(the level at which this chapter is directed) requires that limiting 
assumptions be made about the state of the system when a task issues a 
QIO directive. The following assumptions apply: 

• The system is up and ready to accept an I/O request. All 
required data structures for supporting devices attached to 
the system are intact. 

• The only I/O request in the system is the sample request 
under discussion. 

• The example progresses without encountering any errors that 
would prematurely terminate its data transfer; thus, no 
error paths are discussed. 

The I/O flow proceeds as follows: 

1. [Task issues QIO directive] 

All Executive directives are called by means of EMT 377. The 
EMT causes the processor to push the PSW and PC on the stack 
and to pass control to the Executive's directive processor. 

a. First-level validity checks 

The QIO directive processor validates the LUN and UCB 
pointer. 

b. Redirect algorithm 

Because the UCB may have been dynamically redirected 
by an MCR Redirect command, QIO directive processing 
traces the redirect linkage until the target UCB is 
found. 

c. Additional validity checks 

The EFN and the address of the I/O status block 
(IOSB) are validated. The event flag is reset and 
the I/O status block is cleared. 
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2. [Executive obtains storage for and creates an I/O packet] 

The QIO directive processor now acquires an 18-word block of 
dynamic storage for use as an I/O packet. It inserts into 
the packet data items that are used subsequently by both the 
Executive and the driver in fulfilling the I/O request. Most 
items originate in the requesting task's Directive Parameter 
Block (DPB) . 

3. [Executive validates the function requested] 
The function is one of four possible types: 

• Control 

• No-op 

• ACP 

• Transfer 

Control functions are queued to the driver. If the function 
is^ IO.KIL, the driver is called at its cancel I/O entry 
point. The IO.KIL request is then completed successfully. 

No-op functions do not result in data transfers. The 
Executive "performs" them without calling the driver. No-ops 
return a status of IS.SUC in the I/O status block. 

ACP functions may require processing by the file system. 
More typically, the request is a read or write virtual 
function that is transformed into a read or write logical 
function without requiring file system intervention. When 
transformed into a read or write logical, the function 
becomes a transfer function (by definition). See Appendix D 
for more information on ACP functions. 

Transfer functions are address checked and queued to the 
proper driver. Then the driver is called at its initiator 
entry point. 

4. [Driver processing] 

a. Request work 

To obtain work, the driver calls the $GTPKT routine. 
$GTPKT either provides work, if it exists, or informs the 
driver that no work is available, or that the SCB is 
busy. If no work exists, the driver returns to its 
caller. If work is available, $GTPKT sets the device 
controller and unit to "busy," dequeues an I/O request 
packet, and returns to the driver. If the I/O request is 
10. ATT or I0.DET, the request is processed by the 
Executive without returning the packet to the driver, 
unless UC.QUE is set. 

If UC.QUE is set, the packet is passed to the driver 
after the 10. ATT or IO.DET processing is completed. If 
the request is to be processed by an ACP, the packet is 
queued to the ACP. In either case, $GTPKT will look for 
another request for the driver. 
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Issue I/O 

From the available data structures, the driver initiates 
the required I/O operation and returns to _ its caller. A 
subsequent interrupt may inform the driver that the 
initiated function is complete, assuming the device is 



interrupt driven. 
5. [Interrupt processing] 

When a previously issued I/O operation interrupts, the 
interrupt causes a direct entry into the driver, which 
processes the interrupt according to the programming protocol 
described in Section 2.5. According to the protocol, the 
driver may process the interrupt at priority 7, at the 
priority of the interrupting device, or at fork level, it 
the processing of the I/O request associated with the 
interrupt is still incomplete, the driver initiates further 
I/O on the device (step 4b). When the processing of an I/O 
request is complete, the driver calls $IODON. 

6. [I/O Done processing] 

$IODON removes the "busy" status from the device unit and 
controller, queues an AST, if required, and determines if a 
checkpoint request pending for the issuing task can now be 
effected. The IOSB and event flag, if specified, are 
updated, and $IODON returns to the driver. The driver 
branches to its initiator entry point and looks for more work 
(step 4a). This procedure is followed until the driver finds 
the queue empty, whereupon the driver returns to its caller. 

Eventually, the processor is granted to another ready-to-run 
task that issues a QIO directive, starting the I/O flow anew. 



2.7 DATA STRUCTURES AND THEIR INTERRELATIONSHIPS 

This section introduces all the individual control blocks, as _ well as 
their linkages and use within the system. The following data 
structures comprise the complete set for I/O processing: 

1. Task header 

2. Window Block (WB) 

3. File Control Block (FCB) 

4. $DEVHD word, the Device Control Block (DCB) , and the Driver 
Dispatch Table (DDT) 

5. Unit Control Block (UCB) 

6. Status Control Block (SCB) 

7. Volume Control Block (VCB) 

Figure 2-5, which provides the structure for the following discussion, 
shows all the individual data structures and the important link fields 
within them. The numbers on the figure are keyed to the text to 
simplify the discussion and to guide the reader through the data 
structures. 
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Figure 2-5 I/O Data Structure 



A Window Block (WB) exists for each active access to files on 
a mounted volume. It contains the context for the virtual 
patch used for validating I/O requests and converting virtual 
functions to logical functions. For disks, the WB consists 
of pointers to contiguous areas on the device. 

An FCP is a data structure specific to the Files-11 disk ACP 
(F11ACP) . It is used to control access to the file. 



1. In mapped systems, a copy of the task header (located in the task's 
partition) is made in the Executive's dynamic storage region. The 
Executive then uses this copy. To access the current information in 
this copy, a task must be privileged and have mapping to the 
Executive. 
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4. $DEVHD is a word located in system common (SYSCM) and is the 
other independent entry in the I/O data structure. $DEVHD 
points to a singly linked, unidirectional list of Device 
Control Blocks (DCBs) . Each device type in a system has at 
least one associated DCB. The DCB list is terminated by a 
zero in the link word. 

Linked to each DCB is a Driver Dispatch Table (DDT), which is 
part of the driver. The DDT contains the addresses of the 
driver's four entry points that the Executive can call. 

5. A key data structure is the Unit Control Block (UCB) . All 
the UCBs associated with a DCB appear in consecutive memory 
locations. During internal processing of an I/O request, 
most drivers set R5 to the address of the related UCB. It is 
by means of pointers in the UCB that other control blocks in 
the data structure are accessed. In particular, the UCB 
contains pointers to the DCB, SCB, VCB, and to the UCB to 
which it may have been redirected. If a Redirect command has 
not been issued for the device-unit, the UCB redirect pointer 
points to the UCB itself. When servicing a request for one 
of its UCBs, the driver is unaware of whether I/O was issued 
directly to its own UCB or to a UCB that had been redirected 
to its UCB. 

6. One Status Control Block (SCB) exists for each controller in 
a system. A unique SCB must exist for each 
controller/device-unit capable of performing parallel I/O. 
The SCB contains the fork-block storage required when a 
driver calls $FORK to transfer itself to the fork-processing 
level. The I/O request queue listhead is also contained in 
the SCB. Generally, register R4 contains the address of the 
SCB during processing of an I/O request. 

7. One Volume Control Block (VCB) exists for each mounted volume 
in a system. The VCB maintains volume-dependent control 
information. 

For Fiies-11 disks, the VCB contains pointers to the File 
Control Definition Block (FCB) and Window Block (WB) , which 
control access to the volume's index file. (The index file 
is a file of file headers.) The WB for the index file serves 
the same function as the WB for a user file. (See the 
IAS/RSX-11 I/O Operations Reference Manual for more 
information on the index file.) All unique FCBs for a volume 
form a linked list emanating from the index file FCB. This 
linkage aids in keeping file access time short. Further, 
since the window that contains the mapping pointers is 
variable in length, the user can increase file access speed 
by adding more access pointers (greater speed requires more 
main memory) to whatever extent the application requires. 



2.7.1 Data Structures Summary 

As the writer of a conventional driver, you do not manipulate the 
entire I/O data structure. In fact, you are usually involved only 
with the I/O packet, the UCB, and the SCB. The entire structure has 
been presented to add depth to your understanding of the I/O system, 
to emphasize the relationships among individual control blocks, and to 
clarify further the role a given driver fulfills in the processing of 
an I/O request. 
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CHAPTER 3 
INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 



If you want to support an I/O device for which DIGITAL has not 
supplied a driver, you can write your own driver. Although this 
manual has not yet presented explicit details for writing such a 
driver, you now have enough conceptual information to consider 
incorporating one of your own drivers into your system. As will be 
seen, many considerations for writing a driver are best presented in a 
discussion of incorporating one. 

NOTE 

An alternative approach to writing your 
own device driver may be the CINT$ 
(Connect to Interrupt Vector) directive. 
Refer to the description of the CINT$ 
directive in the RSX-11M/M-PLUS 
Executive Reference Manual . For 
examples of the use of CINT$, examine 
the task-level support routines for 
K-series laboratory peripheral modules, 
as described in Chapter 22 of the 
RSX-11M/M-PLUS I/O D rivers Reference 
Manual. 



3.1 OVERVIEW OP INCORPORATING USER-WRITTEN DRIVERS 

How you incorporate a user-written driver into the system depends 
mainly on whether you make your driver loadable or resident. If your 
driver is loadable, its data base can be either loadable or resident. 
If your driver is resident, both its data base and its code are 
resident. Thus, because you build the Executive image during system 
generation, you must include all resident driver elements in the 
Executive image during system generation. If your driver is loadable 
and has a loadable data base, you can incorporate it at any time after 
you build the Executive under which the driver runs. 



3.1.1 System Generation Support for User-Written Drivers 

During system generation, you answer questions concerning the types 
and quantity of peripheral devices on your system. Based on your 
answers, SYSGEN creates a single source file SYSTB.MAC that 
constitutes the data base definitions for DIGITAL-supplied devices on 
the system. Also created are the object modules of driver code to 
support the devices. Assembling SYSTB.MAC creates on 
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SYSTB.OBJ, which becomes the system device tables for the Executive 
and the data base for the system drivers. This module is linked into 
and becomes a permanent part of the Executive. 

A privileged system task invoked with the MCR/VMR LOA command is 
responsible for loading into memory a driver that is not resident. 
The LOA function creates the necessary interrupt control blocks (ICB) 
for accessing a driver in a mapped system, and establishes the linkage 
between the data base structures in the system device tables and the 
driver code being loaded. Another privileged system task invoked with 
the MCR/VMR UNL command can remove a loadable driver from memory. 
(Although the UNL function removes a loadable driver, it does not 
remove a loadable data base.) 

SYSGEN asks questions concerning the necessary driver support features 
in the Executive, to allow you to add user-written drivers. 

During the Target Configuration section of SYSGEN Phase I, answer the 
following question with the highest vector your system will use with 
the addition of your user-written driver: 

14. Highest interrupt vector [0 R: 0-774 D:0]: 

SYSGEN uses the specified address or 400, whichever is greater, to 
allocate sufficient vector space in the Executive to avoid run-time 
destruction of the system stack and to avoid hardware trapping (which 
occurs when the SP goes below 400). 

If any user-written driver is to be built loadable, SYSGEN must be 
notified of this fact. Loadable drivers require extra Executive 
features to support them (for example, the MCR/VMR LOA and UNL 
commands). You can choose support for loadable drivers by answering 
the following question in the Executive Options section of SYSGEN 
Phase I: 

15. Loadable device drivers? [Y/N] : 

The answer to the following question determines whether SYSGEN allows 
you to include a user-written driver in the system: 

25. Do you intend to include a user-written driver? [Y/N]: 

If you answer Yes, the next two questions are also asked (see Section 
5.3 of this manual): 

26. Include routine $GTWRD? [Y/N]: 

27. Include routine $PTWRD? [Y/N]: 

NOTE 

If an LPA11 device (LA:) is included in 
your system, the $GTWRD routine is 
automatically included and Question 26 
is not asked. If an AD01 A/D controller 
device or an AFC11 A/D controller device 
(AF:) is included in your system, the 
$PTWRD routine is automatically included 
and Question 27 is not asked. The 
$GTWRD and $PTWRD routines are described 
in Chapter 5 of this manual. 

To incorporate a user-written driver into RSX-11M, you first create 
two modules, one in which you define the data base and the other in 
which you include the driver code itself. You then must link your 
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driver data base and driver code modules into the system device 
tables in the Executive. The linkage that your data base module must 
satisfy is the link of the Device Control Block (DCB) list. The 
linkage for the driver code connects the DCB for the device that your 
driver supports to the Driver Dispatch Table (DDT). Moreover, if your 
driver is loadable, you must supply in your driver code symbols and 
labels that the LOA command needs. 

If your driver is loadable and has a loadable data base, you build (1) 
a loadable image containing the driver code module followed by the 
driver data base module, and (2) a symbol definition file on which the 
LOA command depends to find critical data base and driver locations. 
You build the driver image with the symbol definition file of the 
Executive under which the driver runs. However, the driver image is 
separate from the Executive image. The LOA command is responsible for 
loading both your driver data base and driver code, for connecting the 
data base to the system device tables, and for connecting your driver 
code to the data base. 

If your driver is loadable but has a resident data base, you must 
perform SYSGEN and build the Executive under which the driver runs to 
link your driver data base module(s) into the system device tables. 
This operation makes your driver data base resident with the system 
device tables. You also build (1) a loadable image containing the 
driver code, and (2) a symbol definition file which the LOA command 
uses to locate the driver dispatch table. The LOA command is 
responsible for loading your driver code and for connecting your 
driver code to the data base that is resident with the system device 
tables. 

If your driver is resident, you must perform a system generation and 
build the Executive to link the driver data base into the system 
device tables and to include the driver code in the Executive image. 

Because the LOA command provides consistency and validity checks on a 
data base being loaded, DIGITAL recommends that you make your driver 
and its data base loadable. Furthermore, with a loadable driver and 
loadable data base, you can more easily modify your driver and its 
data base. You need not rebuild your Executive and privileged tasks. 
To change the driver code, you need only build a new driver image, 
unload the current version, and reload the new version. To change the 
driver data base, you must build a new driver image (which 
incorporates the data base module) , rebootstrap your system, and load 
the new driver to load the modified data base. (You must bootstrap 
your system to change the data base because the UNL command does not 
unload a data base, and because the LOA command does not load a data 
base for a driver if one is currently loaded for that driver.) 

NOTE 

If you use VMR to load the data base 
into the system image, rebooting the 
system will always load the data base. 

Using a loadable driver with a loadable data base may make more work 
in the short term but saves work in the long term. During debugging, 
data base inconsistencies are likely to be caught by the LOAD command. 
Thus, you prevent many such errors from later creating system 
problems. The procedure to make your driver operational is more 
complex because both the driver (and its data base) must be loaded 
each time the system starts up. 
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A resident driver or a loadable driver with a resident data base is 
easier to incorporate into the system but more difficult to debug and 
to modify. The LOA command does not perform consistency and validity 
checks on a resident data base. Thus, a debugging aid is not 
available. Moreover, to modify such drivers, you must rebuild the 
Executive, which generally implies rebuilding the privileged tasks. 

The capability to incorporate a user-written driver into your system 
is a supported feature of RSX-11M. Because a user-written driver is 
considered a system modification, DIGITAL may not support the system 
that results after you incorporate your driver. Being a part of the 
Executive, your driver can subtly corrupt it. Therefore, DIGITAL 
cannot guarantee support which entails debugging user-written drivers. 

Fixing a problem in a system is largely a matter of being able to 
reproduce the problem reliably. If a problem on your system can be 
shown to have no relation to your driver, and DIGITAL will reproduce 
the problem, SPR support can be provided. A good reason for using a 
loadable driver with a loadable data base is that you can more easily 
test an unmodified system by not loading your driver and its data 
base. You can then reproduce a suspected problem in an unmodified 
system and can submit an SPR that DIGITAL will answer. Therefore, 
attempting to re-create a suspected problem on your system without 
your driver and its data base saves both you and DIGITAL time in 
answering the SPR. 



3.1.2 Overview of User-Written Driver Code 

To create the source code to drive a device, you must do the 
following: 

1. Thoroughly read and understand this manual. 

2. Familiarize yourself in detail with the physical device and 
its operational characteristics. 

3. Determine the level of support required for the device. 

4. Create the data base source code for the device. 

5. Determine actions to be taken at the five driver entry 
points : 

Initiator 

Cancel I/O 

Time-out 

Power fail 

Interrupt 
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6. Create the driver source code. This code will contain the 
following global symbols (where xx is the 2-character 
alphabetic device mnemonic) : 

$xxTBL:: Address of the driver dispatch table (see 
Section 4.1.2.1) 

$xxINT:: Address of the driver interrupt entry point 

$xxINP:: Addresses of input and output interrupt 
$xxOUT:: entry points (for full-duplex devices) 

If a loadable driver's loadable data base is to include the 
interrupt vector (s) for the case when the driver is resident, 
the conditional assembly symbol LD$xx must be included in the 
source code for the loadable data base. In addition, the 
code in the data base which includes the interrupt vector (s) 
must be enclosed in a conditional assembly block and defined 
as an ASECT. 

Loadable drivers have an additional requirement. Either 
within the driver source code itself or in file RSXMC.MAC, 
the conditional assembly symbol LD$xx must be defined. The 
INTSV$ macro (see Section 4.3) uses this symbol (and others 
in RSXMC.MAC) to determine whether the call to $INTSV should 
be omitted from the driver. 

The symbols used to name interrupt entries are different for 
devices that employ error logging. See the RSX-11M/M-PLUS 
Error Logging Reference Manual for information on modifying 
device drivers for error logging. Note that the error logger 
must be modified to log errors for a device that uses a 
user-written driver. 

The DIGITAL-supplied terminal driver (TTDRV) is treated as a 
special case by the LOA command in terms of the naming of its 
interrupt entries. 



3.1.3 Overview of User-Written Driver Data Bases 

Of the data structures associated with an I/O driver, four require 
assembly source code: 

• The DCB 

• The UCB(s) 

• The SCB(s) 

• The device interrupt vector (assembly source required for 
resident drivers only) 
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A single DCB can service multiple UCBs and SCBs . The existence of 
multiple UCBs and SCBs is determined by the actual device subsystem 
being supported by a given driver in your hardware configuration. 
Figures 2-2, 2-3, and 2-4 illustrate possible DCB, UCB, and SCB 
structural relationships. 

Within the DCB, UCBs, and SCBs, only those fields that are static or 
that need initialization must be supplied in your assembly source. 
Tables 3-1, 3-2, and 3-3 list these required fields. See Chapter 4 
for detailed figures and descriptions of these and other data 
structures. 



Offset 



Table 3-1 
Required DCB Fields 



Description 



D.LNK 

D.UCB 

D.NAM 
D.UNIT 

D.UCBL 
D.DSP 



D.MSK 



D.PCB 



Link to next DCB. This field is zero if this is the 
last (or only) DCB. If you are incorporating more 
than one user-written driver at one time, then this 
field should point to another DCB in a DCB chain. 



Address of the first word (U.DCB) of 
associated with this DCB. 



the first UCB 



Two-character ASCII generic device name. 

Highest and lowest logical unit numbers controlled by 
this DCB. 

Length of the UCB (including prefix words, if any) . 
If a given DCB has multiple UCBs, all UCBs must be of 
the same length. 

Address of the driver dispatch table. The dispatch 
table is located within the driver code. This field 
contains a global reference to the label associated 
with this table. The field is zero if the driver is 
loadable. 

I/O function masks. You must supply bit-by-bit 
mapping for these four I/O function masks. Note that 
the format of the mask words is split into two groups 
of four words. Functions 0-15. are covered by the 
first group, and functions 16.-31. by the second. 

Address of driver Partition Control Block (PCB) . 
This field is required only if loadable driver 
support is included in the system. It must be 
initialized to zero. 



3-6 



INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 



Offset 



U.DCB 
U.RED 

U.CTL 

U.STS 
U.UNIT 
U.ST2 
U.CW1 

U.CW2 
U.CW3 
U.CW4 
U.SCB 
U.ATT 



Table 3-2 
Required UCB Fields 



Description 



Backpointer to the associated DCB 

Redirect pointer — initially contains the address of 
this UCB 

Control bits that must be established by the driver 
writer with the UCB source 

Unit status byte 

Physical unit number serviced by this UCB 

Unit status byte extension 

Characteristics word 1; standard description (see 
Section 4.1.4.1) applies 

Driver-dependent 

Driver -dependent 

Default buffer size 

Address of the SCB for this UCB 

TCB address of attached task 



Table 3-3 
Required SCB Fields 



Offset 



S.LHD 
S.PRI 
S.VCT 
S.ITM 
S.CON 

S.STS 
S.CSR 
S.FRK 
S.MPR 



Description 



I/O queue listhead 
Priority of interrupting source 
Interrupt vector address divided by 4 
Initial timeout count 

Controller index (that is, controller number 
multiplied by 2) 

Controller status 

Address of control and status register 

Fork block 

Mapping register block; needed only by UNIBUS NPR 
devices running on a PDP-11 processor that employs 
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3^2 USER-WRITTEN LOADABLE DRIVERS 

In deciding whether the data base for your loadable driver should be 
resident or loadable, consider the following characteristics of 
loadable data bases: 

• When you load a driver, the MCR/VMR LOA command checks to see 
whether a data base is resident for the type of device whose 
driver is being loaded. If a data base is not resident, the 
LOA command reads the driver symbol definition file to find 
the start and end of the data base in the driver image. 
(Thus, if your driver data base is to be loadable, you must 
have defined its start and end in the data base source code.) 
Knowing the start and end, the LOA command reads the data base 
from the driver image. The LOA command places the data base 
in the system pool so that it resides in Executive address 
space, accordingly relocates pointers and links within the 
data base to be valid Executive addresses, and also connects 
DCB(s) in the data base to the system device tables. 
Moreover, the LOA command performs many consistency and 
validity checks on the data base being loaded so as to prevent 
the system device tables from being corrupted by an incorrect 
data base. 

• A loadable data base is only loaded once; thereafter, it is 
resident until the system is bootstrapped again. The UNL 
command does not remove a data base from memory even though 
the data base was loaded with the LOA command. 

• The LOA command relocates certain known pointers within the 
control blocks. 1 If the data base requires relocation of 
additional address pointers beyond the standard ones, it 
cannot be loaded with the LOA command. It must be 
incorporated into the system as a resident data base during 
system generation. 

During debugging of a loadable driver (with loadable data base) , you 
can correct errors in the coding of the driver itself by unloading, 
modifying, assembling, task-building, and reloading the driver. 
However, if the data base must be replaced, the system must be 
bootstrapped to remove it. You can then modify, assemble, and 
task-build the data base, and reload it along with the (corrected) 
driver . 

The subsections below describe the procedure for incorporating a 
user-written loadable driver. 



3.2.1 Creating the Loadable Data Base and Driver Modules 

The general procedure for incorporating a loadable driver with a 
loadable data base is as follows: 

1. Complete SYSGEN Phase I and answer the appropriate questions 
that include the necessary driver support features in the 
Executive. Edit the assembly prefix file RSXMC.MAC and 
define a conditional symbol LD$xx for each loadable driver. 
See Section 3.1.1 for a discussion of system generation 
support. 



1. The pointers are: (DCB) D.LNK, D.UCB; (UCB) U.DCB, U.RED U.SCB. 
(SCB) S.LHD+2. Chapter 4 gives details on these and other fields in 
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2. Complete SYSGEN Phase II. During Phase II you must edit 
RSXBLD.CMD, the Executive build command file (see Section 
3.3), and add the following line: 

GBLDEF=$USRTB:0 

(The symbol $USRTB in the file [11, 10]SYSTB.MAC defines the 
link word to a user-written driver's resident DCB. Adding 
this line forces the link word to be zero.) If you do not add 
this line when you do not have a resident data base, the Task 
Builder generates an undefined symbol error when it builds 
the Executive. However, you can disregard that error because 
the Task Builder sets the contents of the link word to zero. 

3. After SYSGEN Phase II completes, you can manually build the 
driver. 

After completing these steps, you can assemble the driver and data 
base at any time. 

4. While both the loadable driver and its data base can be 
contained in the same source module, it is recommended that 
you create separate sources for your driver and its data base 
and place them in UFD [11,10]. If, however, you place both 
the data base and the driver in the same module, you must 
ensure that, when linked, the data base follows the driver 
code. You can do this by physically placing the data base 
code after the driver code or by using .PSECT names to force 
proper allocation. 

5. A useful convention is to name your data base source xxTAB 
and your driver source xxDRV, where xx is the 2-character 
(alphabetic) device mnemonic. 

6. You must place the DCB first in the assembly source code df 
the driver data base module. In a multiuser protection 
system, the DCB must be followed first by the associated 
UCB(s) and then by the SCB(s). All UCB(s) associated with a 
particular DCB must be contiguous. DIGITAL-supplied drivers 
use this ordering scheme; see the file [11, 10]SYSTB.MAC, 
created by Phase I of SYSGEN, for examples. Since you are 
creating a loadable data base for a single driver, your 
source code will contain a single DCB with associated UCB(s) 
and SCB(s) . 

7. The global label $xxDAT:: marks the start of your driver's 
data base (the DCB). The global label $xxEND: : marks the 
end of the data base (that is, immediately following the 
final word of the data base) . These labels are absolutely 
required. The letters xx represent the 2-character device 
mnemonic. 

To assemble your driver, set the default UIC to [11, 2x] and run the 
assembler as follows (user input underlined): 

> SET /UIC=[ll,2x] @m 

>MAC(H) 

MAC> xxDRV,xxDRV=LB: [1 , 1] EXEMC/ML, LB : [11 , 10]RSXMC ,xxDRV B) 

To assemble the data base, use the following input to MAC: 

MAC> xxTAB,xxTAB=LB: [1 , 1] EXEMC/ML, LB : [11, 10] RSXMCl,xxTAB S) 
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Next, you use the following command to add both the driver and its 
data base to the Executive object module library: 

LBR>LB: [1, 2x] RSX11M/RP=[11, 2x] xxDRV,xxTAB © 



3.2.2 Task-Building a Loadable Driver 

In this section, two examples of task-building a loadable driver with 
a loadable data base are presented: one for a mapped system and one 
for an unmapped system. 



3.2.2.1 Task-Building a Loadable Driver on a Mapped System - The 
following seven requirements apply to task-building any loadable 
driver, whether user-written or DIGITAL-supplied. 

1. You must specify a task image file name and a symbol 
definition file name as TKB output. Both files must be 
placed in the UFD corresponding to the system UIC that will 
be in effect when the command is issued. The file names must 
both be xxDRV, where xx is the device mnemonic. The Task 
Builder produces output files named xxDRV.TSK and xxDRV.STB. 
For example, the beginning of input to TKB to build a 
paper-tape reader driver for a mapped system might appear as 
follows (user input underlined): 

> TKB (jT) 

TKB> [1,54]PRDRV/-HD/-MM,, [1 , 54] PRDRV= <m 

T T T r 

Task image. Switches: see Symbol 

items 2 & 3 definition, 
below. 

2. You must not have a task header. Use the switch /-HD, as in 
the example above. A driver is not really a task but an 
extension of the Executive, and as such needs no task header. 

3. You must use the /-MM switch, whether in fact the driver is 
destined for a mapped or an unmapped system. 

4. You must link to the system symbol definition file that 
contains definitions of Executive global symbols. Continuing 
the paper-tape reader driver example referred to above, 
further TKB input might look like this: 

TKB > LB: [1 , 24] RSX11M/LB : PRDRV: PRTAB (ED 
TKB> [1,54]RSX11M.STB/SS (RET) 

The first line above specifies the library file (/LB) in 
which the input driver object module and the object file for 
the loadable data base can be found. The object module 
specification for the driver must always precede the 
specification for the data base in the TKB command line. 

You omit the data-base file specifier when task-building any 
DIGITAL-supplied driver or one of your own drivers if it has 
a resident data base. All DIGITAL-supplied drivers that are 
declared loadable at system generation use resident data 
bases. 
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The second line in item 4 above indicates that the symbol 
table file RSX11M.STB is to be searched selectively (/SS) for 
definitions of Executive global symbols. Note that the /SS 
switch must appear in this context. It cannot be omitted. 

5. You must link to the system library file that defines masks 
and offsets used in the Executive. Continuing the example: 

TKB> LB; [1 , 1] EXELIB/LB ® 
TKBVdD 

The single slash begins the option phase of the Task Builder. 

6. The driver code will execute as a part of the Executive, and 

f-hng 1-ho riri'wor will ncp l-Vjo irva^iifiitQ c?4-5»/-'k- TV fl rAf A ^ Q *»~,, 

must direct the Task Builder not to allocate space for a 
stack within the driver, as follows: 

TKB> STACK=0 (H) 

7. You must specify a partition for the driver. The 
specification differs for mapped and unmapped systems. 
Continuing the mapped-system example: 

TKB > PAR=DRVPAR: 120000: 4000 (RET) 

TKB>//© 

> 

On mapped systems, the starting address of the partition must 
be 120000 octal. That is, the loadable driver must be mapped 
to kernel APR 5. 

On unmapped systems, the second parameter must be the 
physical starting address of the partition. 

On either mapped or unmapped systems, the length of the 
partition may not exceed 4K words (20000 octal bytes) . 

The double slash terminates the Task Builder's input. 



3.2.2.2 Task-Building a Loadable Driver on an Unmapped System - In 
the example below, we build a magtape driver for an unmapped system. 
The only differences from the mapped-system example are the partition 
starting address and the UFD of some of the files ([1,50] and [1,20] 
instead of [1,54] and [1,24], respectively). 

>TKB® 

TKB> [1,50]MTDRV/-HD/-MM,, [1 , 50]MTDRV= < Ml 

TKB >LB: [1 , 20] RSX11M/LB :MTDRV:MTTAB © 

TKB > [1,50]RSX11M.STB/SS © 

TKB> LB: [1 , 1] EXELIB/LB fRff) 

TKB >/ (fig) 

ENTER OPTIONS : SD 

TKB> STACK=Q gJH 

TKB > PAR=DRVPAR: 34000: 4000 ® 

TKBV/ffi) 

> 
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3.2.3 Loading a User-Written Loadable Driver 

Loading is done by using the privileged MCR command LOA. Its form is: 

LOA xx : [/PAR=partition] 

where xx is the 2-character device mnemonic. Specifying a partition 
is optional. If none is specified, the partition input to the Task 
Builder is used. 

The LOA command requires that the two files xxDRV.TSK and xx DRV. STB 
reside under the system UFD (that is, the UFD established by the SET 
/SYSUIC command). Typically, this UFD is [1,50] for unmapped systems 
and [1,54] for mapped systems. 

LOA searches first for a resident data base for the driver being 
loaded. If none is found, LOA looks for the following global symbols 
in the symbol definition file xxDRV.STB: 

SxxDAT:: Address of the start of the data base (the DCB) 
associated with the driver 

$xxEND: : Address+2 of the last word of the data base 
associated with the driver 



3.2.4 Creating the Loadable Driver and Resident Data Base Modules 

If you decide upon a resident data base, you create the data base 
object module during SYSGEN Phase I. You use the same procedure as 
that for a resident driver. 

To create the resident data base, follow the procedure described in 
Section 3.3 with the exception of initializing the device interrupt 
vector. Since there is only one resident data base module (USRTB, 
which contains all the resident data bases) , you assemble the resident 
data bases for loadable drivers with the resident data bases for 
resident drivers. 

To assemble the loadable driver, use the following command to MAC: 

MAOxxDRV, xxDRV=LB: [1 , 1] EXEMC/ML, LB : [11 , 10] RSXMC ,xxDRV © 



3.2.5 Building a Loadable Driver and Its Resident Data Base 

You build all resident data bases into the Executive as described in 
Section 3.3. You build the loadable drivers after the Executive is 
built. When SYSGEN asks the following question during Phase II: 

5. Driver 2-character device mnemonic [S]: 

enter the characters xx, where xx is the driver name. 

After your system is built, you can load your driver as described in 
Section 3.2.3. 
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3.3 USER-WRITTEN RESIDENT DRIVERS 

This section describes specific details for user-written resident 
drivers. 

1. Create the assembly source file for the resident data base in 
UFD [11,10]. Use USRTB.MAC as the file specification. USRTB 
as the file name is not actually required. It is, however, a 
useful convention — as reflected in the sample dialogue 
described below. 

2. There is no mandatory ordering of the different control 
blocks in the data base, for your resident driver. It is 
suggested that you follow the convention of placing the DCB 
first, followed by the UCB(s), followed by the SCB's^. 
However, it is required that all UCB(s) associated with a 
particular DCB must be contiguous. DIGITAL-supplied RSX-llM 
drivers use this ordering scheme; see the file [11,10] 
SYSTB.MAC, created by Phase I of SYSGEN, for examples. If 
you are incorporating multiple resident drivers into your 
system, you will have more than one instance of a DCB with 
UCB(s) and SCB(s) . 

3. Initialize the device interrupt vector (refer to Section 
4.1.5 for a description of this process). 

4. Use the global label $USRTB:: as the address of your first 
(or only) DCB. This is absolutely required. 

During Phase I, SYSGEN asks: 

25. Do you intend to include a user-written driver? [Y/N] 

If you answer Yes, then subsequent questions guide you through the 
process of adding the driver to the generated system. Refer to 
Section 3.1.1 for a discussion of system generation support and the 
questions asked. Operations performed include assembling the driver 
and its data structure, and editing the RSX-llM task-build command 
file. 

The following sample dialogue illustrates the addition of a resident 
driver for a PK: device. All user responses are underlined. After 
SYSGEN assembles the DIGITAL-supplied drivers, it prints some 
instructions, then pauses to allow you to assemble your driver (s), as 
follows: 



Assemble user-written driver (s) 

The following instructions apply to resident drivers and 
loadable drivers with resident data bases. 

For loadable drivers, you must ensure that a symbol definition 
of the format: 

LD$xx=0 
(where xx is the device name) appears in the assembly prefix 
file [11,10]RSXMC.MAC for each loadable driver xxDRV. 
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SYSGEN will now pause to allow you to assemble your drivers(s) 
and USRTB module. Using a driver name xxDRV (where xx is 
the device name; for example, DK) , you can type commands 
in the following format to assemble the driver and USRTB 
modules. 

MAC 

MAOxxDRV=LB: [1 , 1] EXEMC/ML, SY: [11, 10]RSXMC ,xxDRV 

MAOUSRTB=LB: [1 , 1] EXEMC/ML, SY: [11 , 10]RSXMC , USRTB 

MAO~Z 



AT. — PAUSING. TO CONTINUE TYPE "RES AT." 

> 

>MAC (RET) 

MAC> PKDRV=LB; [1 , 1] EXEMC/ML, SY: [U, 10]RSXMC , PKDRV (ret) 

MAC MJSRTB=LB: [1, 1] EXEMC/ML, SY: [11, 10] RSXMC , USRTB ilP 

MAOH) 

> 

> RES ...AT. (RED 

AT. — CONTINUING 
> 

After you exit from MACRO-11 and type the command to resume, SYSGEN 
finishes Phase I. 

When you start Phase II, SYSGEN asks a few questions, prints some 
instructions, and pauses for you to build the driver (s) as follows: 



Build user-written driver (s) 

You must now edit the Executive build command file RSXBLD.CMD 

to include your user-written driver and data base in your system. 

If you are including a resident data base, locate the line 
in which the module SYSTB is referenced and add : USRTB 
immediately after it, for example: 

LB: [ 1, 24 ] RSX1 1M/LB : SYSTB: USRTB : SYTAB : INITL, LB: [1 , 1] EXELIB/LB/SS 
If you are not including a resident data base, add the line 

GBLDEF=$USRTB:0 
to the file instead. 

For each resident driver, add a line of the form: 

LB: [l,24]RSXHM/LB:xxDRV 
where other drivers are referenced (where xx is the device name, 
for example DK) . 

NOTE: For each loadable driver, do not add a corresponding 
line to the build command file 

SYSGEN will now pause to allow you to edit RSXBLD.CMD. 
After you exit from the editor and resume, SYSGEN builds the 
Executive and drivers. 



AT. — PAUSING. TO CONTINUE TYPE "RES ...AT." 

> EDI RSXBLD.CMD ®. 

[00028 LINES READ IN] 

[PAGE 1] 

* L SYSTB dD 

LB: [1, 24 ]RSXllM/LB: SYSTB: SYTAB: INITL, LB: [1 , 1] EXELIB/LB/SS 

*C /SYSTB : /SYSTB : USRTB : /(ret) 
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LB : [1 , 24] RSX11M/LB : S YSTB : USRTB : SYTAB : INITL, LB : [1 , 1] EXELIB/LB/SS 

* L DYDRV (BD 

[*EOB*] 

*T(RCT) 

* L DYDRV dH 

LB: [1,24]RSX11M/LB:DYDRV 

*I® 

LB: [1,24]RSX11M/LB:PKDRV 

*EX_® 
[EXIT] 

> RES ...AT. (ret) 

AT, — CONTINUING 

After you perform the indicated operations and type the command to 
continue with SYSGEN, the Executive is built and you are given a 
chance to build any loadable drivers as follows: 

>; Build Loadable drivers 

>; 

>* 4. Build all selected loadable drivers into DRVPAR? [Y/N]:Y 

>; 

>; You can now build your user-written driver (if it is a loadable 
>; driver) . If you choose not to build it now, or it is not loadable 
>; strike carriage return in response to the next question. 

>; 

>; When all drivers are built, strike carriage return 

>; 

>* 5. Driver 2-character device mnemonic [S]: 

When Phase II completes, your resident driver is incorporated in the 
Executive and is ready to run. 



3.4 DRIVER DEBUGGING 

Because the protection checks provided for user programs are not 
available to system modules, driver errors are more difficult to 
isolate than user-program errors. But conventional drivers, because 
they are modular and short, probably can be easily debugged. This 
debugging process requires that you understand the following topics, 
each of which is discussed in a separate subsection: 

• Debugging aids and tools 

• Fault isolation 

• Fault tracing 

• Rebuilding and reincorporating a driver 
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3.4.1 Debugging Aids 

Adding a user-written driver carries with it the risk of introducing 
obscure bugs into an RSX-llM system. Since the driver runs as part of 
the Executive, special debugging tools are both desirable and 
necessary. RSX-llM provides several such aids, which can be 
incorporated into your system during system generation: 

• Executive stack and register dump 

• XDT 

• Panic dump 

• Crash Dump Analyzer (CDA) support routine. 

You need not select any of this software during system generation. 
If, however, you do require the facilities they offer, you can select 
from one to three of them for incorporation in your system (panic dump 
and the CDA support routine are mutually exclusive) . The following 
subsections describe the features and use of each debugging aid. 



3.4.1.1 Executive Stack and Register Dump Routine - At system 

generation, you can indicate that you want a dump of the Executive 

stack and the registers when a crash occurs. If you choose this 
option, the system will perform as follows: 

1. A system error, or the XDT X command (described in the next 
section) , or operator manipulation of the switch register 
following a CPU halt, will cause processing to resume at 
location 40(octal). 

2. Location 40 (octal) contains a JMP instruction that causes the 
Executive to execute the code beginning at location $CRASH. 

3. $CRASH invokes the routine that dumps the Executive stack and 
registers as shown below: 

SYSTEM CRASH AT LOCATION 047622 

REGISTERS 
R0=000340 Rl=177753 R2=000353 R3=000000 
R4=000004 R5=046712 SP=000472 PS=000340 

SYSTEM STACK DUMP 

LOCATION CONTENTS 

000472 000004 

000474 000000 

000476 001514 

000500 000340 

000502 177753 

000504 000353 

000506 000000 

000510 000000 

000512 057750 
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000514 002504 

000516 030011 

000520 100340 

000522 000340 

000524 056446 

000526 000000 

000530 102144 

000532 000000 

000534 101376 

000536 101372 

000540 102022 

000542 170000 

Following this display, either the CDA support routine or panic dump 

is invoked, depending on which (if either) is present in the system. 
Otherwise, the system halts. 



3.4.1.2 XDT - The Executive Debugging Tool - An interactive debugging 
tool has been developed for RSX-11M to aid in debugging Executive 
modules, I/O drivers, and interrupt service routines. This debugging 
aid, called XDT, is a version of the RSX-11 Octal Debugging Tool 
(ODT) . XDT does not contain the following features and commands 
available on ODT: 

No $M - (Mask) register 

No $X - (Entry Flag) registers 

No $V - (SST vector) registers 

No $D - (I/O LUN) registers 

No $E - (SST data) registers 

No $W - (Directive Status Word) $DSW word 

No E - (Effective Address Search) command 

No F - (Fill Memory) command 

No N - (Not word search) command 

No V - (Restore SST vectors) command 

No W - (Memory word search) command 

In addition, the X (Exit) ODT command has been changed for XDT. The X 
command causes a jump to the crash-reporting routine. 

Except for the omitted features and the change in ^the_J(_ jjommand , XDT 
is command-compatible with RSX-11 ODT; consequently, the IAS/RSX-11 
ODT Reference Manual can be used as a guide to XDT operation. 

XDT may be included in a system during Phase I of SYSGEN. The 
following question is asked: 

*30. Executive Debugging Tool (XDT)? [Y/N] : 
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If you answer Yes, then XDT is automatically included in the generated 
system. When the resultant system is bootstrapped, XDT takes control 
and types on the console terminal: 

XDT: <system version> 

followed by the prompting symbol 

XDT> 

You can set breakpoints at this time, and then type the G command, 
passing control to the RSX-11M Executive initialization code. 
Whenever control reaches a breakpoint, a printout similar to that 
produced by RSX-11 ODT occurs. 

You can initiate a forced entry to XDT at any time from a privileged 
terminal by means of the MCR BRK (breakpoint) command. Thus, the 
normal procedure is to type G when the system is bootstrapped without 
setting any breakpoints. When it becomes necessary to use XDT, the 
MCR BRK command is executed, causing a forced breakpoint. XDT then 
prints on the console terminal: 

BE:xxxxxx 

followed by the prompting symbol 

XDT> 

You can then set breakpoints and/or issue other XDT commands. 
Continue system operation by typing the P (proceed) command to XDT. 

Note that XDT runs entirely at priority level 7 and does not interfere 
with user-level RSX-11 ODT. In other words, user-level RSX-11 ODT can 
be in use with several tasks, while XDT is being used to debug 
Executive modules. 

All XDT command I/O goes to and from the console terminal, and the L 
(List Memory) command can list on either the console or the line 
printer. 

Using XDT to debug a loadable driver on a mapped system has special 
pitfalls. One problem that can arise is a T-bit error: 

TE:xxxxxx 

XDT> 

This error results when control reaches a breakpoint that you have 
set, using XDT, in a loaded driver on a mapped system. The T-bit 
error, rather than the expected BE: error, occurs unless register 
APR5 is mapped to the driver at the time XDT sets the breakpoint. 

To avoid this T-bit error, assemble the driver with an embedded BPT 
instruction, or use either the ZAP utility or the MCR OPE command to 
set the breakpoint by replacing a word of code with the BPT 
instruction. When control reaches a breakpoint set in this manner, 
XDT prints: 

BE:xxxxxx 
XDT> 
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Recover as follows: Using XDT, replace the BPT instruction with the 
desired instruction. Decrement the PC by subtracting 2 from the 
contents of register R7. Then proceed by using the P or S commands. 

NOTE 

You should not set breakpoints in more 

than one module that maps into the 

Executive through APR 5 or APR 6. In 
particular, do not set breakpoints in 

more than one loadable driver at a time 

or XDT will overwrite words of main 

memory when it attempts to restore the 
contents of breakpoints. 



3.4.1.3 Panic Dump - The Panic Dump routine saves registers RO 
through R6 and then halts, awaiting dump limits to be entered. 

The procedure for entering dump limits depends on whether your 
processor has a console switch register. The subsections that follow 
describe the procedure in each instance. 

3.4.1.4 Using the Panic Dump Routine on Processors with Console 
Switch Registers - For processors with console switch registers, you 
can obtain dumps of selected blocks of memory by using the following 
procedure : 

1. Enter the low dump limit in the console switch register and 
press CONT. The processor will immediately halt again. 

2. Enter the high dump limit in the console switch register and 
press CONT. The dump will begin on the device whose CSR 
address is D$$BUG (usually 177514, which is the line 
printer). The actual value of D$$BUG is determined during 
system generation when answering the panic dump question. At 
the end of the dump, the processor will again halt, awaiting 
the input of another set of dump limits. 

If your system does not have the Executive routine stack and 
register dump, enter the dump limits 0-520 (octal) when the 
Panic Dump routine first halts. This causes dump of the 
system stack and the general registers. The limit 520(octal) 
changes if the highest interrupt vector is above 400 (octal). 
The actual upper limit is always the value of the global 
symbol $STACK and can be obtained from the global symbol 
listing in the Executive memory allocation map. 



3.4.1.5 Using the Panic Dump Routine on Processors Without Console 
Switch Registers - A number of PDP-11 processors are being delivered 
without a console switch register; they are configured with the M9301 
Console Emulator and Bootstrap. This presents no problem for the 
normal operation of RSX-11M, because it does not require a switch 
register. However, the Panic Dump Routine usually reads its arguments 
from the switch register. In systems that have been generated for 
processors that have no switch register, the panic dump module has 



3-19 



INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 

been altered to read its arguments from location 0. The following 
instructions are designed to allow you to enter the proper information 
to the Panic Dump Routine on processors equipped with the M9301 
Console Emulator. 

1. When the Panic Dump Routine halts, the RUN light will go out. 
At this time press and release the BOOT switch. 

The Console Emulator should display: 

XXXXXX XXXXXX XXXXXX nnnnnn 

$ 

where nnnnnn is the address+2 of the HALT instruction. 

2. You should enter the following: 

$ L 1 

$ D low-address (RET) 
$ L nnnnnn fRET) 
$S gui 

3. The processor should again halt. Press and release the BOOT 
switch. 

The Console Emulator should display: 

XXXXXX XXXXXX XXXXXX mmmmmm 
$ 

4. You should then enter: 

$L 0W) 

$ D high-address gjT) 

$ L mmmmmm (ret) 

$S_!rFD 

At this time the dump should commence. When it is finished, the 
processor will halt and wait for additional input. 



3.4.1.6 Sample Output from Panic Dump - A portion of the output from 
Panic Dump is shown below. Output is in 3-line groupings. In the 
left-hand column, two addresses are shown. The first address is the 
absolute address; the second address is the dump relative address. 
The first line in a 3-line group gives the octal word value; the 
second line gives the two octal byte values of the word; the third 
line contains the ASCII representation of the bytes. The ASCII 
representations in each word are reversed to improve readability. The 
first output grouping from Panic Dump shows, proceeding from left to 
right, the address/absolute address, PS, R0, Rl, R2, R3, R4, R5, and 
the SP. 



000544 000000 046076 000066 000000 000000 000000 000000 045316 

000000 000 000 114 076 000 066 000 000 000 000 000 000 000 000 112 316 

~<? ~@ > L 6 "@ *@ *@ ~@ ~@ ~@ ~@ ~@ "@ n J 

000000 022646 000340 045770 000340 045770 000340 045770 000340 

000000 045 246 000 340 113 370 000 340 113 370 000 340 113 370 000 340 

& % ~@ K *@ K ~@ K ~@ 
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000020 045776 000340 011124 000340 045770 000340 050500 000340 

000020 113 376 000 340 022 124 000 340 113 370 000 340 121 100 000 340 

K *§ T ~R *6 K "@ @ Q "@ 

000040 000167 000543 000001 000001 000000 000000 000000 000353 

000040 000 167 001 143 000 001 000 001 000 000 000 000 000 000 000 353 

~@ "A "A ~g "A ~@ ~@ ~@ ~@ ~@ "@ ~@ ~@ 

000060 035444 000340 034034 000340 032776 000340 032402 000340 

000060 073 044 000 340 070 034 000 340 065 376 000 340 065 002 000 340 

$ ; ~@ "\ 8 "§ 5 *g ~B 5 *§ 



3.4.1.7 Crash Dump Analyzer Support Routine - The Crash Dump Analyzer 
(CDA) support routine, when entered, prints the following message on a 
notification device specified at SYSGEN: 

CRASH - CONT WITH SCRATCH MEDIA ON device mnemonic 

You can then put the secondary crash dump device on line and depress 
the CONT switch on the operator's console. The Executive Crash Dump 
routine will dump memory to the crash dump device and halt the 
processor upon completion. 

The procedure for subsequently invoking the Crash Dump Analyzer, which 
reads and formats the memory dump, is fully documented in the RSX-11M 
Crash Dump Analyzer Reference Manual . 



3.4.2 Fault Isolation 

Four causes can be identified when the system faults: 

• A user-state task has faulted in such a way that it causes the 
system to fault. 

• The user-written driver has faulted in such a way that it 
causes the system to fault. 



• 



The RSX-11M system software itself has faulted. 



• The host hardware has faulted. 

When the system faults, you must immediately determine which of these 

four causes is responsible. This section presents some procedures 

that can help you isolate the source of the fault. Correcting the 
fault itself is your responsibility. 



3.4.2.1 Immediate Servicing - Faults manifest themselves in roughly 

four ways (they are listed here in order of increasing difficulty of 
isolation) : 

1. If XDT is included, an unintended trap to XDT occurs. 

2. The system displays text indicating a crash has occurred and 
halts . 



3-21 



INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 

3. The system halts but displays nothing. 

4. The system is in an unintended loop. 

The immediate aim, regardless of the fault manifestation, is to get to 
a point where you can obtain pertinent fault isolation data. 

The following discusssions assume the existence of a system built with 
at least one of the debugging aids described in Section 3.4.1. (Note 
that the minimal system does not have space for these routines.) 

Case 1 — The system has trapped to XDT: 

The trap may or may not be intended (for example, a previously set 
breakpoint). If it is not intended, type the X command, causing XDT 
to exit to location 40 (octal), from which the Executive stack and 
register dump routine (if present), followed by either Panic Dump or 
the CDA support routine (if present), will be invoked. If, however, 
you have some idea of the source of the problem (for example, a recent 
coding change) , then you can use XDT to examine pertinent data 
structures and code. 

Case 2 — The system has displayed text indicating a crash has occurred: 

If the text consists of output from the Executive stack and register 
dump routine (refer to Section 3.4.1.1), all the basic information 
describing the state of the system has been displayed. If the text 
has been produced by the CDA support routine, follow the procedure for 
obtaining and formatting a memory dump as outlined in the RSX-11 Crash 
Dump A nalyzer Reference Manual . 

Case 3 — The system has halted but displays no information: 

Before taking any action, preserve the current PS and PC and the 
pertinent device registers (that is, examine and record the 
information these registers contain). The procedure depends on the 
particular PDP-11 processor. Consult the PDP-11 Processor Handbook 
for details. 

After preserving the PS and PC, invoke your resident debugging aid: 
enter 40(octal) in the switch register, press LOAD ADDR, and then 
press START. The contents of 40 (octal) cause the successive 
invocation of: 

1. The Executive stack and register dump routine (if present) 

2. Either Panic Dump or CDA support routine (if present) 
Case 4 — The system is in an unintended loop: 

Proceed as follows: 

1. Halt the processor. 

2. Record the PC, the PS, and any pertinent device registers, as 
in case 3 above. 

You may then want to step through a number of instructions in an 
attempt to locate the loop. For this attempt to be meaningful you 
must first disable the system clock. Proceed as follows: Examine the 
contents of word 777546 (if your system has a line-frequency clock) or 
word 772540 (if it has a programmable clock) . Clear bit 6 in this 
word and redeposit the word. 
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NOTE 

The system will not run until you have 
reenabled the clock. 

After trying to locate the loop and reenabling the clock, transfer to 
location 40(octal), as in case 3. 



3.4.2.2 Pertinent Fault Isolation Data - Before you attempt to locate 
the fault, you should dump system common (SYSCM) . SYSCM contains a 
number of critical pointers and listheads. Find the appropriate 
limits for the module SYSCM by examining the Executive memory 
allocation map. Enter these limits to the Panic Dump routine or 
specify them in the command line used to invoke the Crash Dump 
Analyzer. 

In addition, you should dump the dynamic storage region and the device 
tables. The dynamic storage region is the module INITL and any 
additional space gained from the SET /POOL command and the device 
tables are in SYSTB. 

At this point, you have the following data: 

• Processor Status Word (PSW) 

• Program counter (PC) 

• Stack 

• RO through R6 

• Pertinent device registers 

• Dynamic storage region (pool) 

• Device tables 

• System common 

These data are the minimum required for effectively tracing the fault. 

3.4. 3 Fault Tracing 

Three pointers in SYSCM are critical in fault tracing. These pointers 
are described below: 

$STKDP - Stack Depth Indicator 

This data item indicates which stack was being used at the time 
of the crash. $STKDP plays an important role in determining the 
origin of a fault. The following values apply: 

+1 — User (task-state) stack 

or less — System stack 
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If the stack depth is +1, then the user has crashed the system. 
In a system with "brickwall" protection (for example, the mapped 
RSX-11M system) , the nonprivileged user should not be able to 
crash the system. 

$TKTCB - Pointer to the current Task Control Block (TCB) 

This is the TCB of the user-level task in control of the CPU. 

$HEADR - Pointer to the current task header. 

The $HEADR word points to the header of the task currently 
running. The task header provides additional data to help 
isolate a fault. Figures 3-1 and 3-2 show the layout of task 
headers for unmapped and mapped systems, respectively. 

The first word in the header is the user's stack pointer (SP) the 
last time it was saved. If the user branches wildly into the 
Executive, the Executive terminates the user task, but the system 
continues to function (possibly erroneously). Knowing the user's 
stack pointer provides one more link in the chain that may lead 
to the resolution of the fault. 

The header (as pointed to by $HEADR) also contains the last-saved 
register set, just before the header guard word (the last word in 
the header — pointed to by H.GARD). 



RO 



R1 



R2 



R3 



H.NLUN 
H.GARD 



H.HDLN 



Length in bytes 



SP 



PS 



PC 



R5 



R4 



ZK-215-S1 



Figure 3-1 Task Header on an Unmapped System 
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RO 



R5 



PC 



PS 



H.NLUN 
H.GARD 



H.HDLN 



Length in bytes 



SP 



Figure 3-2 Task Header on a Mapped System 



3.4.3.1 Tracing Faults Using the Executive Stack and Register Dump - 

To trace a fault after a display of the Executive stack and register 
contents, first examine the system stack pointer. Usually an 
Executive failure is the result of an SST-type trap within the 
Executive. If an SST does occur within the Executive, then the origin 
of the call on the crash-reporting routine is in the SST service 
module. (The crash call is initiated by issuing an IOT at a stack 
depth of zero or less.) 

A call to crash also occurs in the Directive Dispatcher when an EMT is 
issued at a stack depth of zero or less, or a trap instruction is 
executed at a stack depth of less than zero. The stack structure in 
the case of an internal SST fault is shown in Figure 3-3. 
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PS 



PC 



R5 



R4 



R3 



R2 



R1 



RO 



Return to system exit 



Zero or more SST parameters 



SST fault code 



Number of bytes 



■SP 



Figure 3-3 Stack Structure: Internal SST Fault 



The fault codes are: 





2 

4 

6 

10 

12 

14 

16 

20 

22 

24 

26 

30 

32 

34 



ODD ADDRESS AND TRAPS TO 4 

MEMORY PROTECT VIOLATION 

BREAK POINT OR TRACE TRAP 

IOT INSTRUCTION 

ILLEGAL OR RESERVED INSTRUCTION 

NON RSX EMT INSTRUCTION 

TRAP INSTRUCTION 

11/40 FLOATING POINT EXCEPTION 

SST ABORT -BAD STACK 

AST ABORT -BAD STACK 

ABORT VIA DIRECTIVE 

TASK LOAD READ FAILURE 

TASK CHECKPOINT READ FAILURE 

TASK EXIT WITH OUTSTANDING I/O 

TASK MEMORY PARITY ERROR 



The PC points to the instruction following the one that caused the SST 
failure. The number of bytes is the number normally transferred to 
the user stack when the particular type of SST occurs. If the number 
is 4, then a non-normal SST fault occurred, and only the PSW and PC 
are transferred. There are no SST parameters. 

If the failure is detected in $DRDSP, the stack is the same as that 
shown in Figure 3-3, except that the number of bytes, the SST fault 
code (the fault codes are listed above) , and the SST parameters are 
not present. The crash report message, however, will indicate that 
the failure occurred in $DRDSP. 
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One SST-type failure, stack underflow, does not result in the stack 
structure of Figure 3-3. To determine where the crash occurred, first 
establish the stack structure; this can be deduced by the value of 
the SP and the contents of the top word on the stack. If the stack 
structure is that of Figure 3-3, then the failure occurred in $DRDSP, 
or was a normal SST crash. If the stack structure is that of Figure 
3-4, then an abnormal SST crash has occurred. 



SP 



PS 



PC 



ZK-218-81 

Figure 3-4 Stack Structure: Abnormal SST Fault 
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You now have all the information needed to isolate the cause of the 
failure. From this point on, rely on personal experience and a 
knowledge of the interaction between the driver and the services 
provided by the Executive. 



3.4.3.2 Tracing Faults When the Processor Halts Without Display - To 

trace a fault when the processor halts but displays no information 
(case 3 in Section 3.4.2.1 above), first examine $STKDP, $TKTCB, and 
$HEADR. The difficulty in tracing failures in this case is that the 
system stack is not directly associated with the cause of a failure. 

By examining $STKDP, you can determine the system state at the time of 
failure. If it was in user state, the next step is to examine the 
user's stack. The examination focuses on scanning the stack for 
addresses that may be subroutine links that can ultimately lead to a 
thread of events isolating the fault. This is essentially the aim of 
looking at the system stack if $STKDP is zero or less. 



Frequently, a fault can occur that causes the SP to point to the top 
of the stack plus 4. This fault results from issuing an RTI 
instruction. The top two items on the stack 
a wild branch and 



from 
are data. The result is 
then, most probably, a halt. Figure 3-5 shows a 
two data items are on the stack when the program 
RTI instruction. The top of the stack points to a word 
containing 40100 (octal) . If location 40100 (octal) contains a HALT 
instruction, the original SP is four bytes below the final SP, and 
fault tracing should begin from the original SP. 



case in which 
executes an 
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40100 



•SP 



•SP 



Figure 3-5 Stack Structure: Data Items on Stack 



This type of fault also occurs when an RTS instruction is executed 
with an inconsistent stack. However, in that case, SP points to 
TOS+2. 

A scan of the contents of the general registers may give some hint as 
to the neighborhood in which a fault (or the sequence of events 
leading up to the fault) occurred. 

If the fault occurred in a new driver, a frequent source of clues is 
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT), 
as are the activity flags (US.BSY and S.STS). Other locations in both 
the UCB and SCB may also provide information that may help locate the 
source of the fault. 



3.4.3.3 Tracing Faults After an Unintended Loop - To trace a 
when an unintended loop has occurred, first halt the processor. 



fault 



After you halt the processor, the same state exists as was discussed 
in Section 3.4.3.2. Follow the same tracing procedure described 
there. A specific suggestion is to check for a stack overflow loop. 
Patterns of data successively duplicated on the stack indicate a stack 
looping failure. 



3.4.3.4 Additional Hints for Tracing Faults - Another item to check 
is the current (or last) I/O packet, the address of which is found in 
S.PKT of the SCB. The packet function (I.FCN) defines the last 
activity performed on the unit. 

If trouble occurred in terminating an I/O request, a scan of the 
system dynamic memory region may provide some insight. This region 
starts at the address contained in $CRAVL, a cell in SYSCM. Because 
all I/O packets are built in system dynamic memory, their memory is 
returned to the dynamic memory region when they are successfully 
terminated. Following the link pointers in this region may reveal 
whether I/O completion proceeded to that point. In systems with QIO 
optimization, $PKAVL (SYSCM) points to a list of I/O packet-sized 
blocks of dynamic memory that are not linked into the $CRAVL chain. 

A frequent error for an interrupt-driven device is to terminate an I/O 
packet twice when the device is not properly disabled on I/O 
completion and an unexpected interrupt occurs. This action ultimately 
produces a double deallocation of the same packet of dynamic memory. 
Double deallocation of a dynamic buffer in RSX-11M causes a loop in 
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the module $DEACB on the next deallocation (of a block of higher 
address) after the second deallocation of the same block. At that 
time, R2 and R3 both contain the address of the I/O packet memory that 
has been doubly deallocated. If XDT has been included in the system, 
the deallocation routine checks for bad deallocation and crashes the 
system if it occurs. 



3.4.4 Rebuilding and Reincorporating a Driver 

The procedure for rebuilding and reincorporating a driver into your 
system depends on whether the driver is resident or loadable. The two 
subsections that follow describe the procedure for each kind of 
u river • 



3.4.4.1 Rebuilding and Reincorporating a Resident Driver - The 
procedure for rebuilding and reincorporating a resident driver 
involves four steps: 



NOTE 
In the examples that follow: 

• x (as in [11, 2x] is equal to 
for unmapped systems and 4 for 
mapped systems 

• xxDRV is the name of the driver 
you are rebuilding or 
reincorporating 

1. Correct and assemble the driver and/or device data 
structures. 

Assuming that the object system has been bootstrapped, 
appropriate volumes have been mounted, and the source code 
for the user driver and/or device data base has been updated, 
then the following commands effect the reassembly of both the 
driver and the data base: 

> SET /UIC=[ll,2x] (E), 

>RUN_$MAC(H) 

MAC > xxDRV=LB: [1, 1]EXEMC/ML, SY: fll, 10]RSXMC,xxDRV © 
MAC> USRTB=LB: [1, 11 EXEMC/ML, SY: [11, 10]RSXMC , USRTBdD 
MAOlBi " ' — ■ 

2. Update the Executive object module library. 

After reassembling the user driver and/or data base, you must 
update the Executive object module library. The following 
commands will accomplish this: 

> SET /UIC=[1,2x] (ret) 
> RUN $LBR (reT) 

LBR> LB : RSX11M/RP= [ 1 1, 2X1 xxDRV. USRTB fRET) 
LBR>ETruz) 
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3. Do Phase II of SYSGEN to rebuild the driver with the 
Executive. 

4. Bootstrap the new system. 

The new system can now be bootstrapped with the MCR BOO 
command. If you are using the baseline system, first issue 
the following command: 

> INS BOO; -K B) 

Then issue the following command: 

>B00 [l,5x]RSXllM(H) 



3.4.4.2 Rebuilding and Reincorporating a Loadable Driver - A loadable 
driver is easier to reincorporate during debugging than a resident 
driver. After correcting and assembling the driver source, simply 
unload the old version, using the MCR UNL command, task-build the new 
one, and load it using the LOA command. 

The data structure, once loaded, becomes a permanent part of the 
Executive. It is not removed by the UNL command. If the data 
structure is in error and cannot be patched, correct its source, 
reassemble, and task-build it. Then bootstrap the system before 
loading the corrected driver. 
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CHAPTER 4 
WRITING AN I/O DRIVER — PROGRAMMING SPECIFICS 

In Chapter 2, overviews were given for: 

• Data structures 

• Executive services 

• Programming protocol 

This chapter gives details for the data structures, and in addition 
discusses specifics of multicontroller drivers and the INTSV$ macro. 
Executive services are covered in Chapter 5. The protocol coverage in 
the discussion of programming protocol in Chapter 2 is detailed enough 
to make further elaboration unnecessary. 

4.1 DATA STRUCTURES 

The following elements in the I/O data structure are of concern to the 
programmer writing a driver: 

• I/O packet 

• DCB 

• UCB 

• SCB 

• Device interrupt vector 

The I/O data structure, and the first four control blocks listed above 
in particular, contain an abundance of data pertaining to input/output 
operations. Drivers themselves are involved with only a subset of the 
data. 

In the detailed descriptions of the I/O packet, the DCB, the UCB, and 
the SCB that follow, most data fields (words or bytes) are classified 
by one of five descriptions. Two items in each description indicate: 

• Whether the field is initialized in the data structure source 

• What sort of access the driver has to the field during 
execution 
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The five descriptions are: 

initialized , not referenced> 

Field is supplied in the data structure source code, and is 
not referenced by the driver during execution. 

initialized, read-only> 

Field is supplied in the data structure source code, and may 
be read by the driver. 

<not initialized, read-only> 

Either an agent other than the driver establishes this field, 
or the driver sets it up once and thereafter references it 
read-only. 

<not initialized, read-write> 

Either the driver or some other agent establishes this field, 
and the driver may read it or write over it. 

<not initialized, not referenced> 

Field does not involve the driver in any way. 

These five descriptions cover most of the fields in the four control 
blocks described in this section. Exceptions are noted in the text. 

The final discussion in this section deals with the device interrupt 
vector. 



4.1.1 The I/O Packet 

Figure 4-1 shows the layout of the 18-word I/O packet, which is 
constructed and placed in the driver I/O queue by QIO directive 
processing, and is subsequently delivered to the driver by a call to 
$GTPKT. The DPB from which the I/O packet is generated is illustrated 
in Figure 4-2 (see Section 4.1.1.2). 



4.1.1.1 I/O Packet Details - The I/O packet is built dynamically by 
QIO directive processing. Thus, no static fields exist with respect 
to a driver. I/O packets are created dynamically, and therefore the 
first two descriptions in Section 4.1 (<initialized , not referenced> 
and initialized, read-only>) do not apply. Fields in the I/O packet 
(described below) are classified as not referenced, read-only, or 
read-write. 

I.LNK 

Driver access: 

Not referenced. 

Description: 

Links I/O packets queued for a driver. A zero ends the 
chain. The listhead is in the SCB (S.LHD). 
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I.EFN 



Driver access: 

Not referenced. 

Description: 

Contains the event flag number as copied by QIO directive 
processing from the requester's DPB. 



1 1 MIS' 
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I.TCB 


TCB address of requester 
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I.LN2 


Address of second LUT word 
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I.UCB 


Address of redirect UCB 


10 


I.FCN 


Function code 


Modifier 


12 


I.IOSB 


Virtual address of I/O status block 


14 




Relocation bias of IOSB 


16 




Real address of IOSB 


20 


LAST 


Virtual address of AST service routine 


22 


I.PRM 




24 










Device 






parameters 
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Figure 4-1 I/O Packet Format 

Driver access: 

Not referenced* 
Description : 

Priority copied from the TCB of the requesting task. 
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I.TCB 

Driver access: 

Read-only. 

Description : 

TCB address of the requesting task. 

I.LN2 

Driver access: 

Not referenced. 

Description : 

Contains the address of the second word of the LUT entry in 
the task header to which the I/O request is directed. For 
open files on file-structured devices, this word contains the 
address of the window block; otherwise, it is zero. 

I.UCB 

Driver access: 

Read-only. 

Description : 

Contains the address of the unit to which I/O is to be 
directed. I.UCB is the address of the Redirect UCB if the 
starting UCB has been subject to an MCR RED command. Used in 
cancel I/O routine to determine if the I/O request is from 
the task that is issuing the $IOKIL routine. 

I.FCN 

Driver access: 

Read-only. 

Description: 

Contains the function code (see Table 4-1, Section 4.1.2.2) 
for the I/O request. The modifier byte is one or more 
subf unction bits that may be set. 

I.IOSB 

Driver access: 

Not referenced. 

Description: 

I.IOSB contains the virtual address of the I/O Status Block 
(IOSB) , if one is specified, or zero if one is not specified. 

I.IOSB+2 and I.IOSB+4 contain the address doubleword for the 
IOSB (see Appendix A for a detailed description of the 
address doubleword) . On an unmapped system, the first word 
is zero; the second word is the real address of the IOSB. 
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In a mapped system, the first word contains the relocation 
bias of the IOSB; the bias is, in effect, the number of the 
32-word block in which the IOSB starts. This block number is 
derived by viewing available real memory as a collection of 
32-word blocks numbered consecutively, starting with 0. 
Thus, if the IOSB starts at physical location 3210{octal), 
its block number is 32 (octal). 

The second word is formatted as follows: 

Bits 0-5 Displacement in block (DIB) 
Bits 6-12 All zeros 
Bits 13-15 6 

Hie Q i&pj. dCtJJllSn u ill D±vC& xo ufic unaci. J_rv-»ili i-nc uj.\j\~i\ kjao^m 

In the above example, in which the IOSB starts at 
3210(octal), the DIB is equal to lO(octal). 

The value 6 in bits 13-15 is constant. It is used to cause 
an address reference through Kernel Address Page Register 6 
(APR6) . Again, see Appendix A for details. 

Discussion of the address doubleword is deferred to an 
appendix because you seldom have to be concerned with its 
contents or format in writing a conventional driver. Its 
construction and subsequent manipulation are normally 
external to the driver. Subroutines are provided as 
Executive services for programmed I/O to render the 
manipulations of I/O transfers transparent to the driver 
itself. 



LAST 



Driver access: 

Not referenced. 

Description : 

Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero. 



I.PRM 



Driver access: 

Not initialized, read-only. 

Description: 

Device-dependent parameters constructed from the last six 
words of the DPB. Note that if the I/O function is a 
transfer (refer to the description of D.MSK in Section 
4.1.2.1), the buffer address (first DPB device-dependent 
parameter) is translated to an equivalent address doubleword. 
Therefore, device-dependent parameter n is copied to I.PRM 
+(2*(n-l) )+2, where n is the number of the parameter and the 
first parameter is numbered PI. 
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4.1.1.2 The QIO Directive Parameter Block (DPB) - The QIO DPB is 
constructed as shown in Figure 4-2. 

The parameters in the DPB have the following meanings. 

Length (required): 

The length of the DPB, which for the RSX-11M QIO directive is 
always fixed at 12 (decimal) words. 

DIC (required) : 

Directive Identification Code. For the QIO directive, this value 
is 1. For QIOW it is 3. 

Function Code (required) : 

The code of the requested I/O function (0 through 31.). 



Length 


DIC 





Function code 


Modifier 


2 


Reserved 


LUN 


4 


Priority 


EFN 


6 


I/O status block address 


10 


AST address 


12 




14 






Device- 
dependent 




parameters 
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Figure 4-2 QIO Directive Parameter Block (DPB) 

Modifier : 

Device-dependent modifier bits. 
Reserved : 

Reserved byte; must not be used. 
LUN (required) : 

Logical Unit Number. 
Priority: 

Request priority. Ignored by RSX-11M. 
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EFN (optional): 

Event flag number. Zero indicates no event flag. If you specify 
no event flag, QIOW$ directives are converted to QIO$ directives. 

I/O Status Block Address (optional): 

This word contains a pointer to the I/O status block, which is a 
2-word, device-dependent, I/O-completion data packet formatted 
as: 

Byte 

I/O status byte. 
Byte 1 

Augmented data supplied by the driver. 

Bytes 2 and 3 

The contents of these bytes depend on the value of byte 0. 

If byte equals 1, then these bytes usually contain the 

processed byte count. If byte does not equal 0, then the 
contents are device-dependent. 

AST Address (optional): 

Address of an AST service routine. 

Device Dependent Parameters: 

Up to six parameters specific to the device and I/O function to 
be performed. Typically, for data transfer functions, the 
following four are used: 

• Buffer address 

• Byte count 

• Carriage control type 

• Logical block number 

The fields for any optional parameters not specified will be filled 
with zeros. 



4.1.2 The Device Control Block (DCB) 

Figure 4-3 is a schematic layout of the DCB. The DCB describes the 
static characteristics of a device controller and the units attached 
to the controller. All fields must be specified except D.PCB, which 
is required only if you selected the loadable-driver option. 
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4.1.2.1 DCB Details - The fields in the DCB are described below: 
D.LNK (link to next DCB)1 

Driver access: 

Initialized, not referenced. 

Description : 

Address link to the next DCB. A zero in this field indicates 
the last (or only) DCB in the chain. 

D.UCB (pointer to first UCB) 

Driver access: 

Initialized, not referenced. 



D.LNK 


Link to next DCB (0=last) 





D.UCB 


Link to first UCB 


2 


D.NAM 


Generic device name 


4 


D.UNIT 


Highest unit no. 


Lowest unit no. 


6 


D.UCBL 


Length of UCB 


10 


D.DSP 


Address of driver dispatch table 


12 


D.MSK 


Legal function mask bits 0-15. 


14 




Control function mask bits 0-15. 


16 




No-op function mask bits 0-15. 


20 




ACP function mask bits 0-15. 


22 




Legal function mask bits 16.-31. 


24 




Control function mask bits 16.-31. 


26 




No-op function mask bits 16.-31. 


30 




ACP function mask bits 16.-31. 


32 


D.PCB 


1 Address of partition control block 


: 34 

j 






ZK 
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Figure 4-3 Device Control Block 



1. Parenthesized phrases indicate value to be initialized in the data 
base source code. 
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Description: 

Address link to the U.DCB field of the first, and possibly 
the only, UCB associated with the DCB. For a given DCB, all 
UCBs are in contiguous memory locations and must all have the 
same length. 

D.NAM (ASCII device name) 

Driver access: 

Initialized, not referenced. 

Description: 

Generic device name in ASCII by which device units are 
mnemonically referenced. 

D.UNIT (unit number range) 

Driver access: 

Initialized, not referenced. 

Description: 

Unit number range for the device. This range covers those 
logical units available to the user for device assignment. 
Typically, the lowest number is zero, and the highest is n-1, 
where n is the number of device-units described by the DCB. 

D.UCBL (UCB length) 

Driver access: 

Initialized, not referenced. 

Description: 

The UCB can have any length to meet the needs of the driver 
for variable storage. However, all UCBs for a given DCB must 
have the same length. The specified length must include the 
following prefix words if any or all are present: 

U.IOC 

U.ERHL 

U.ERHC 

U.ERSL 

U.ERSC 

U.LUIC 

U.OWN 

U.CLI 

U.MUP 
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D.DSP (dispatch table pointer) 

Driver access: 

Initialized, not referenced. 

Description : 

Address of the driver dispatch table. 

When the Executive wishes to enter the driver at any of the 
four entry points contained in the driver dispatch table, it 
accesses D.DSP, locates the appropriate address in the table, 
and calls the driver at that address. A zero table address 
indicates that the (loadable) driver is not in memory. For a 
loadable driver, then, this field must be initialized to 
zero. If the driver does not process a given function, then 
this address points to a return instruction within the 
driver's code. 

You must provide a driver dispatch table in the driver 
source. The label on this table is of the form $xxTBL; it 
must be a global label. The designation xx is the 
2-character generic device name for the device. Thus, $TTTBL 
is the global label on the driver dispatch table for the 
generic device name TT. This table is an ordered, 4-word 
table containing the following entry points: 

• I/O initiator 

• Cancel I/O 

• Device timeout 

• Power failure 

When a driver is entered at one of these entry points, entry 
conditions are as follows: 

At initiator: 

If UC.QUE=1 

R5 = UCB address 
R4 = SCB address 
Rl = Address of the I/O packet 

If UC.QUE=0 

R5 = UCB address 

Interrupts are allowed. (UC.QUE is a bit in U.CTL in the 
UCB. See Section 4.1.4.1.) 

At cancel I/O: 

R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

Rl = Address of TCB of current task 

RO = Address of active I/O packet 

Device interrupts at or below the priority of the 
requesting device are locked out. 
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At device time-out: 

R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

R2 = Address of device CSR 

RO = I/O status code IE.DNR (Device Not Ready) 

Device interrupts at or below the priority of the 
requesting device are locked out. 

At power failure: 

R5 = UCB address 
R4 = SCB address 
R3 = Controller index 

Interrupts are allowed. The power failure entry point of 
a loadable driver is called by LOA only for units that are 
on line and have UC.PWF set. 

D.MSK (function masks) 

Driver access: 

Initialized, not referenced. 

Description: 

There are eight words, beginning at D.MSK, that are critical 
to the proper functioning of a device driver. The Executive 
uses these words to validate and dispatch the I/O request 
specified by a QIO directive. Four masks, with two words per 
mask, are described by the bit configurations that vou 
establish for these words: 

• Legal function mask 

• Control function mask 

• No-op function mask 

• ACP function mask 

The QIO directive allows for 32 possible I/O functions. The 
masks, as stated, are filters to determine validity and I/O 
requirements for the subject driver. 

The Executive filters the function code in the I/O request 
through the four masks. The I/O function code is the 
high-order byte of the function parameter issued with the QIO 
directive. The decimal representation of that high-order 
byte is equivalent to the decimal bit number of the mask. If 
you want the function to be true in one of the four masks, 
you must set the bit in that mask in the position that 
numerically corresponds to the function code. For example, 
the code for IO.RVB is 21 (octal) and its decimal 
representation is 17. If you want IO.RVB to be true for a 
mask, you must set bit number 17(decimal) in the mask. 

The masks are laid out in memory in two 4-word groups. Each 
4-word group covers 16 function codes. The first 4 words 
cover the function codes 0-15; the second 4 words cover 
codes 16-31. Below is the layout used for the driver example 
in Section 6.2.2. 
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LEGAL FUNCTION MASK CODES 0-15. 
CONTROL FUNCTION MASK CODES 0-15. 
NO-OP FUNCTION MASK CODES 0-15. 
ACP FUNCTION MASK CODES 0-15. 
LEGAL FUNCTION MASK CODES 16.-31. 
CONTROL FUNCTION MASK CODES 16.-31. 
NO-OP FUNCTION MASK CODES 16.-31. 
ACP FUNCTION MASK CODES 16.-31. 

sk words filter sequentially as follows: 
Legal Function Mask: 

Leqal function values have the corresponding bit position in 
this word set to 1. Function codes that are not legal are 
rejected by QIO directive processing, which returns IE. IPC in 
the I/O status block, provided an IOSB address was specified. 

Control Function Mask: 



.WORD 


140033 


.WORD 


30 


.WORD 


140000 


.WORD 





• WORD 


5 


• WORD 





.WORD 


1 


.WORD 


4 


The mask word 



If any device-dependent data exists in the DPB, and this data 
does not require further checking by the QIO directive 
processor, the function is considered to be a control 
function. Such a function allows QIO directive processing to 
copy the DPB device-dependent data directly into the I/O 
Packet. 

No-op Function Mask: 

A no-op function is any function that is considered 
successful as soon as it is issued. If the function is a 



no-op, QIO directive processing immediately marks the request 
successful; no additional filtering occurs. 

ACP Function Mask: 

If a function code is legal but specifies neither a control 
function nor a no-op, then it specifies either anACP 
function or a transfer function. If a function code requires 
intervention of an Ancillary Control Processor (ACP), the 
corresponding bit in the ACP function mask must be set. acp 
function codes must have a value greater than 7. 

In the specific case of read-write virtual functions, you 
have the option to set the corresponding mask bits. If the 
corresponding mask bits for a read-write virtual function are 
set, QIO directive processing recognizes that a f ile-oriented 
function is being requested to a non-f lie-structured device 
and converts the request to a read-write logical function. 



This conversion is particularly useful, 
read-write virtual function to a specific device: 



Consider 



1. 



If the device is file structured and a file is open 
on the specified LUN, the block number specified is 
converted from a virtual block number in the file to 
a logical block number on the medium, and the request 
is queued to the driver as a read-write logical 



function. 
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If the device is file structured and no file is open 
on the specified LUN, then an error is returned and 
no further action is taken. 

If the device is not file structured, then the 
request is simply transformed to a read-write logical 
function and is queued to the driver. (Specified 
block number is unchanged.) 



Transfer Function Processi 



ng : 



Finally, if the function is not an ACP function, then by 

™ ul , ** ". a transfer function. All transfer functions 

cause the QIO directive processor to check the specified 

uui. — "^"-j KL-uau ± a , mciusion witnm the address 

space of the requesting task) and proper alignment (word or 
byte). In addition, the processor checks the number of bytes 
being transferred for proper modulus (that is, nonzero and a 
proper multiple) . 

Creating Mask Words: 

Creating function mask words involves five steps: 

1. Establish the I/O functions available on the device 
for which driver support is to be provided. 

2. Build the legal function mask: Check the standard 
RSX-11M function mask values in Table 4-1 for 
equivalencies. Only the IO.KIL function is 
mandatory. 10. ATT and IO.DET functions, if used, 
must have the RSX-11M system interpretation. DIGITAL 
suggests that functions having an RSX-11M system 
counterpart use the RSX-llM code, but this is 
required only when the device is to be used in 
conjunction with an ACP. From the supported function 
list in Table 4-1, you can build the two legal 
function mask words. 

3. Build the control function mask by asking: 

Does this function carry a standard buffer address 
and byte count in the first two device-dependent 
parameter words? 

If it does not, then either it qualifies as a control 
function, or the driver itself must effect the 
checking and conversion of any addresses to the 
format required by the driver. See Section 6.3 for 
an example of a driver that does this. (Buffer 
addresses in standard format are automatically 
converted to address doubleword format.) 

Control functions are essentially those functions 
whose DPBs do not contain buffer addresses or counts. 
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Create the 
legal func 
for compati 
Record 
non-f ile-st 
functions 
though no s 
deaccess a 
access/deac 



no-op function mask by deciding which 
tions are to be set as no-ops. Typically, 
bility with File Control Services (FCS) or 
Management Services (RMS) on 
ructured devices, the file access/deaccess 
are selected as legal functions, even 
pecific action is required to access or 
non-file-structured device; thus, the 
cess functions are set to be no-ops. 



5. 



Finally, include the ACP functions Write Virtual 
Block and Read Virtual Block for those drivers that 
support both read and write. (Include only one 
related ACP function if the driver supports only read 
or write.) 



D.PCB (Partition Control Block) 
Driver access: 

Initialized, not referenced. 

Description: 

Address of the driver's Partition Control Block (PCB) . This 
word is present in the DCB if and only if the loadable-driver 
SYSGEN option has been selected. It must be initialized to 
zero. You can extend the DCB by adding words after D.PCB. 

A PCB exists for every partition in a system. MCR creates a 
PCB when the SET /MAIN or SET /SUB commands are given. If a 
driver is loadable, its PCB describes the partition in which 
it resides. 

The Executive uses D.PCB together with D.DSP (the address of 
the driver dispatch table) to determine whether a driver is 
loadable or resident, and, if loadable, whether it is in 
memory. Zero and nonzero values for these two pointers have 
the meanings shown in Table 4-1. 



Table 4-1 
D.PCB and D.DSP Bit Definitions 



D.DSP: 




D.PCB: 



= 



¥0 



= 


¥0 


Loadable 
driver, 
not in 
memory 


Resident 
driver 


(not 
possible) 


Loadable 
driver, 
in memory 



ZK-223-81 
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4.1.2.2 Establishing I/O Function Masks - Table 4-2 is supplied to 
assist you in determining the proper values to set in the function 
masks. The mask values are given for each I/O function used by 
DIGITAL-supplied drivers. The bit number allows you to determine 
which mask group to use: for bits numbered through 15, use the mask 
value for a word in the first 4-word group; for bits numbered 16 
through 31, use the mask value for a word in the second 4-word group. 



Table 4-2 
Mask Values for Standard I/O Functions 



Bit 


Mask 


Related 


I/O 


# 


v a± uc 




T?l 1 f» r* 4- I r*. *i 
J. LaiIv- I.J.WU 





1 


IO.KIL 


Cancel I/O 




2 


IO.WLB 


Write Logical Block 


2 


4 


IO.RLB 


Read Logical Block 


3 


10 


10. ATT 


Attach Device 


4 


20 


IO.DET 


Detach Device 


5 


40 




General Device Control 


6 


100 




General Device Control 


7 


200 




General Device Control 


8 


400 




Diagnostics 


9 


1000 


IO.FNA 


Find File in Directory 


10 


2000 


IO.ULK 


Unlock Block 


11 


4000 


IO.RNA 


Remove File from Directory 


12 


10000 


IO.ENA 


Enter File in Directory 


13 


20000 


IO.ACR 


Access File for Read 


14 


40000 


I0.ACW 


Access File for Read/Write 


15 


100000 


10. ACE 


Access File for Read/Write/Extend 


16 


1 


IO.DAC 


Deaccess File 


17 


2 


IO.RVB 


Read Virtual Block 


18 


4 


IO.WVB 


Write Virtual Block 


19 


10 


10. EXT 


Extend File 


20 


20 


IO.CRE 


Create File 


21 


40 


10. DEL 


Mark File for Delete 


22 


100 


10. RAT 


Read File Attributes 


23 


200 


10. WAT 


Write File Attributes 


24 


400 


IO.APC 


ACP Control 


25 


1000 




Unused 


26 


2000 




Unused 


27 


4000 




Unused 


28 


10000 




Unused 


29 


20000 




Unused 


30 


40000 




Unused 


31 


100000 




Unused 



Of the function mask values listed in Table 4-2, only IO.KIL is 
mandatory and has a fixed interpretation. However, if 10. ATT and 
IO.DET are used, they must have the standard meaning. (Refer to the 
RSX-11M/M-PLUS I/O Drivers Reference Manual for a description of 
standard I/O functions.) If QIO directive processing encounters a 
function code of 3 or 4 and the code is not set to be a no-op, QIO$ 
assumes that these codes represent Attach Device and Detach Device, 
respectively. The other codes are suggested but not mandatory. You 
are free to establish all other function-code values on 
non-file-structured devices. The mask words must reflect the proper 
filtering process. 
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If a driver is being written for a file-structured device, 
standard function mask values of Table 4-2 must be established. 



the 



Tables 4-3, 4-4, and 4-5 are guides to determining the proper bit 
masks for disks, tapes, and unit record devices (such as terminals, 
card readers, line printers, and paper tape punches/readers). 



Table 4-3 
Mask Word Bit Settings for Disk Drives 



Bit 
# 


RSX-11M 


Related 
Symbolic 


ACP 


non-ACP 







c 


c 


IO.KIL 


1 




t 


t 


IO.WLB 


2 




t 


t 


IO.RLB 


3 




c 


c 


10. ATT 


4 




c 


c 


IO.DET 


5 








IO.STC 


6 










7 




sa 




IO.CLN 


8 




sd 




Diagnostic 


9 




a 




IO.FNA 


10 




a 




IO.ULK 


11 




a 




IO.RNA 


12 




a 




IO.ENA 


13 




a 


n 


IO.ACR 


14 




a 


n 


IO.ACW 


15 




a 


n 


10. ACE 


16 




a 


n 


IO.DAC 


17 




a 


a 


IO.RVB 


18 




a 


a 


IO.WVB 


19 




a 




10. EXT 


20 




a 




I0.CRE 


21 




a 




IO. DEL 


22 




a 




10. RAT 


23 




a 




10. WAT 


24 




a 




IO.APC 


25 










26 










27 










28 










29 










30 










31 










t - 


transfer function, bit set 
function mask 


only in legal 


c - 


control function, bit se 
control function masks 


b in legal and 


n - 


no-op function, bit set in 
function masks 


Legal and no-op 


a - 


ACP function, bit set in 
function masks 


legal and ACP 


sa - 


special case, bit set only 
mask, but not legal 


in ACP function 


sd - 


special case, bit set onl< 
support in system and drive 


/ if diagnostic 

r 
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Table 4-4 
Mask Word Bit Settings for Magnetic Tape Drives 



Bit 

# 


RSX-11M 


Related 
Symbolic 


ACP 


non-ACP 







c 


c 


IO.KIL 




1 


t 


t 


IO.WLB 




2 


t 


t 


IO.RLB 




3 


c 


c 


10. ATT 




4 


c 


c 


IO.DET 




5 


c 


c 


IO.STC 




6 


c 


c 






7 


sa 




IO.CLN 




8 


sd 


sd 


Diagnostic 




9 


a 




IO.FNA 




10 






IO.ULK 




11 






IO.RNA 




12 


n 




IO.ENA 




13 


a 


n 


IO.ACR 




14 


a 


n 


IO.ACW 




15 


a 


n 


10. ACE 




16 


a 


n 


IO.DAC 




17 


a 


a 


IO.RVB 




18 


a 


a 


IO.WVB 




19 


a 




10. EXT 




20 


a 




I0.CRE 




21 






IO. DEL 




22 


a 




10. RAT 




23 






10. WAT 




24 


a 




IO.APC 




25 










26 










27 










28 










29 










30 










31 








t 


- transfer function, bit set only in legal function 




mask 


c 


- control function, bit set in legal and control 




function masks 


n 


- no-op function, bit set in legal and no-op 




function masks 


a 


- ACP function, bit set in legal and ACP function 




masks 


sa 


- special case, bit set only in ACP function mask, 




but not legal 


sd 


- special case, bit set only if diagnostic support 




in system and driver 
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Table 4-5 
Mask Word Bit Settings for Unit Record Devices 



Bit 
# 


RSX-11M 


Related 
Symbolic 


ACP 


non-ACP 







c 


c 




IO.KIL 




1 


t 


t 




IO.WLB 




2 


t 


t 




IO.RLB 




3 


c 


c 




10. ATT 




4 


c 


c 




IO.DET 




5 








IO.STC 




6 












7 


sa 






10 . CLN 




8 


sd 






Diagnostic 




9 


a 






IO.FNA 




10 


a 






IO.ULK 




11 


a 






I0.RNA 




12 


a 






IO.ENA 




13 


a 


n 




IO.ACR 




14 


a 


n 




IO.ACW 




15 


a 


n 




10. ACE 




16 


a 


n 




I0.DAC 




17 


a 


a 




IO.RVB 




18 


a 


a 




IO.WVB 




19 


a 






10. EXT 




20 


a 






IO.CRE 




21 


a 






10. DEL 




22 


a 






10. RAT 




23 


a 






10. WAT 




24 


a 






IO.APC 




25 












26 












27 












28 












29 












30 












31 










t 


- transfer function, bit set onl 
mask 


y in legal function 


c 


- control function, bit set in 
function masks 


legal and control 


n 


- no-op function, bit set ir 
function masks 


legal and no-op 


a 


- ACP function, bit set in legal 
masks 


and ACP function 


sa 


- special case, bit set only in 
but not legal 


ACP function mask, 


sd 


- special case, bit set only if 
in system and driver 


diagnostic support 
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4.1.3 The Status Control Block (SCB) 

Figure 4-4 is a layout of the SCB. The SCB describes the status of a 
control unit that can run in parallel with all other control units. 



s.rcntM 

S.ROFF 1 ) 


Offset to 1st | Number of registers 
device register j to copy on error 






S.BMSV 1 


Saved I/O active bit map 
pointer to Error Message Block 






S.BMSK 1 


Device I/O active bit mask 




S.LHD 


Device i 


/O ciueue 

lead 









list 


2 


S.PRI i 
S.VCT f 


Vector address-r4 


Device priority 


4 


S.CTM \ 
S.ITM f 


Time-out count: 
Initial Current 


6 


S.CON \ 
S.STS / 


Controller status 


Controller index 


10 


S.CSR 


Address of control status register 


12 


S.PKT 


Address of current I/O packet 


14 


S.FRK 


Fork link word 


16 




Fork PC 


20 




Fork R5 


22 




Fork R4 


24 




Relocation base of driver's partition 




26 


S.MPR 


Storage required for 

NPR UN I BUS devices 
with 22-bit addressing 


- 


30 
















L 


-J 





1. These offsets exist for mass storage devices only, and only in systems 
incorporating error logging. 

ZK-224-81 

Figure 4-4 Status Control Block 
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4.1.3.1 SCB Details - The fields in the SCB are described below: 
S.RCNT (used for error logging) 

Driver Access: 

Not initialized, not referenced. 

Description: 

The number of registers to copy on error. This offset exists 
for mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging. 

S.ROFF (used for error logging) 

Driver Access: 

Not initialized, not referenced. 

Description : 

Offet to first device register. This offset exists for mass 
storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 

S.BMSV (used for error logging) 

Driver access: 

Not initialized, not referenced. 

Description : 

Saved I/O active bit map and pointer to Error Message Block. 

This offset exists for mass storage devices only (that is, 

when DV.MSD is set) , and only in systems incorporating error 
logging. 

S.BMSK (used for error logging) 

Driver access: 

Not initialized, not referenced. 

Description : 

Device I/O active bit mask. This offset exists for mass 
storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 

S.LHD (first word equals zero; second word points to first) •*■ 

Driver access: 

Initialized, not referenced. 



1. Parenthesized contents indicate values to be initialized in the 
data base source code. 
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Description: 

Two words forming the I/O queue listhead. The first word 
points to the first I/O packet in the queue, and the second 
word points to the last I/O packet in the queue. If the 
queue is empty, the first word is zero, and the second word 
points to the first word. 

S.PRI (device priority) 

Driver access: 

Initialized, read-only. 

Description: 

Contains the priority at which the device interrupts. Use 
symbolic values (for example, PR4) to initialize this field 
in your data base source. You define these symbolic values 
by issuing the HWDDF$ macro (refer to the sample data base in 
Section 6.2.1 and the listing of the HWDDF$ macro in Appendix 
C). 

S.VCT (interrupt vector divided by 4) 

Driver access: 

Initialized, not referenced. 

Description: 

Interrupt vector address divided by 4. For loadable drivers, 
the MCR/VMR LOA function uses this field and the existence of 
driver symbol (s) $xxINT, $xxINP, and $xxOUT to initialize the 
device interrupt vector. 

S.CTM (initialize to zero) 

Driver access: 

Not initialized, read-write. 

Description : 

RSX-11M supports device time-out, which enables a driver to 
limit the time that elapses between the issuing of an I/O 
operation and its termination. The current time-out count 
(in seconds) is initialized by moving S.ITM (initial time-out 
count) into S.CTM. The Executive clock service (in module 
TDSCH) examines active times, decrements them, and, if they 
reach zero, calls the driver at its device time-out entry 
point. 

The internal clock count is kept in 1-second increments. 
Thus, a time count of 1 is not precise because the internal 
clocking mechanism is operating asynchronously with driver 
execution. The minimum meaningful clock interval is 2 if you 
intend to treat time-out as a consistently detectable error 
condition. Note, if the count is 0, that no time-out occurs; 
a zero value is, in fact, an indication that time-out is not 
operative. The maximum count is 255. You are responsible 
for setting this field. Resetting occurs at actual time-out 
or within $FORK. 
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S.ITM (set to initial time-out count) 

Driver access: 

Initialized, read-only. 

Description: 

Contains the initial time-out value. 

S.CON (controller number times 2) 

Driver access: 

Initialized, read-only. 

Description : 

Controller number multiplied by 2. Drivers that are written 
to support more than one controller use this field. A driver 
may use S.CON to index into a controller table created and 
maintained internally by the driver itself. By indexing the 
controller table, the driver can service the correct 
controller when a device interrupts. See Section 4.2 for an 
example. 

S.STS (initialize to zero) 

Driver access: 

Initialized, not referenced. 

Description: 

Establishes the controller as busy/not busy (nonzero/zero). 
This byte is the interlock mechanism for marking a driver as 
busy for a specific controller. The byte is tested and set 
by $GTPKT and reset by $IODON. 

S.CSR (Control Status Register address) 

Driver access: 

Initialized, read-only. 

Description : 

Contains the address of the Control Status Register (CSR) for 
the device controller. The driver uses S.CSR to initiate I/O 
operations and to access, by indexing, other registers 
related to the device that are located in the I/O page. This 
address need not be a CSR; it need only be a member of the 
device's register set. It is accessed at system bootstrap 
time to determine if the interface exists on the system 
hosting the Executive. The Executive uses S.CSR to set the 
off-line bit at bootstrap so that system software can be 
interchanged between systems without an intervening system 
generation. The MCR LOA function also references S.CSR when 
it processes a loadable data base. Otherwise, only the 
driver itself accesses S.CSR. 
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S.PKT (reserve one word of storage) 

Driver access: 

Not initialized, read-only. 

Description: 

Address of the current I/O packet established by $GTPKT. The 
Executive uses this field to retrieve the I/O packet address 
upon the completion of an I/O request. S.PKT is not zeroed 
after the packet is completed. 

S.FRK (reserve four or five words of storage) 

Driver access: 

Not initialized, not referenced. 

Description: 

The four words starting at S.FRK are used for fork block 
storage if and when the driver deems it necessary to 
establish itself as a fork process. Fork block storage 
preserves the state of the driver, which is restored when the 
driver regains control at fork level. This area is 
automatically used if the driver calls $FORK. 

The fork block is five words long instead of four if two 
conditions are met: 

1. Loadable drivers have been selected as a SYSGEN 
option. 

2. The system is mapped. 

If these conditions are met, and the fork block is five words 
long, you must not use the fork block for any other purpose. 
In other words, you cannot share the space reserved for the 
fork block; if you attempt to do so, you will destroy the 
loadable driver's relocation base. In addition, the 5-word 
fork block should always be part of the SCB if the two 
conditions above are met. 

S.MPR (reserve six words of storage) 

Driver access: 

Initialized, read-only. 

Description: 

Drivers use the six words starting at S.MPR for non-processor 

request (NPR) devices attached to a processor with 22-bit 

addressing. See Appendix B for details on initializing 
S.MPR. 



4.1.4 The Unit Control Block (UCB) 

Figure 4-5 is a layout of the UCB (a variable-length control block) . 

fine FIPR pyi'cf c ff\ r oanh nhucinal Howino-nnif fronarafo^ lrtf-n a cucfom 

configuration. For user-added drivers, this control block is defined 
as part of the source code for the driver data structure. 
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4.1.4.1 UCB Details - The fields in the UCB are described below. 
Note that the fields drawn with dotted outlines are not present in 
every UCB; their existence depends on physical device type, whether 
the system is generated with error logging, and whether you are 
running on a multiuser system. Refer to the individual descriptions 
of the offsets for details. 

U.IOC 

Driver access: 

Not initialized, not referenced. 

Description : 

For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the total 
number of QIOs issued to the device. (Initialized to zero 
when device is mounted.) 

U.ERSL 

Device access: 

Not initialized, not referenced. 

Description : 

For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the maximum 
number of soft errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U. ERHL or in U.ERSL) is exceeded. 

U.ERHL 

Driver access: 

Not initialized, not referenced. 

Description : 

For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the maximum 
number of hard errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U.ERHL or in U.ERSL) is exceeded. 

U.ERSC 

Driver access: 

Not initialized, not referenced. 

Description: 

For mass storage devices only (that is, when DV.MSD is set), 

and only in systems incorporating error logging: the total 

number of soft errors logged on the device. (Initialized to 
zero when device is mounted.) 
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U . ERHC 

Driver access: 

Not initialized, not referenced. 

Description: 

For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the total 
number of hard errors logged on the device. (Initialized to 
zero when device is mounted.) 

NOTE 

The following two symbolic names, U.MUP 
and U.CLI, both refer to the same 
absolute offset; use of the offset is 
dependent on system software 
configuration. Details regarding the 
use of each symbolic name are contained 
in the descriptions of U.MUP and U.CLI. 

U.MUP 

Driver access: 

Not initialized, not referenced. 

Description: 

For terminal UCBs only, and only in multiuser systems that 
include alternate CLI support: bits 1 to 4 contain an index 
to a table which contains the address of CLI Parser Block 
(CPB) for the current CLI; the remaining bits are used for 
other terminal-specific features, and defined as follows: 

UM.OVR Override CLI indicator 

UM.CLI CLI indicator 

UM.DSB Terminal disabled because CLI eliminated 

UM.NBR No broadcast 

U.CLI 

Driver' access: 

Not initialized, not referenced. 

Description : 

For systems without alternate CLI support, but which do 
include multiuser protection: multiuser protection flag 
word. 

U.LUIC 

Driver access: 

Not initialized, not referenced. 

Description : 

For terminal UCBs only, and only in multiuser systems: the 
login UIC of the user at the particular terminal. 
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U.IOC 4 

U.ERSL 4 \ 
U.ERHL 4 { 



U.ERSC 4 
U.ERHC 4 

U.MUP 3 
U.LUIC r 



r 1 

J- — — — — I/O count — — — — _| 

Hard error limit Soft error limit I 

|- — — — — — t — — — — — -J ^ See note 5 
Hard error count Soft error count , | 

I-""---- 1 "I I 

Multiuser flags and CLI pointer 

u H 





} 

} 


i-uyi 




U.OWN 1 


Owning terminal UCB address 


U.DCB 


Back pointer to DCB 


U.RED 


Redirect UCB pointer 


U.CTL 
U.STS 


Unit status 


Control flags 


U.UNIT 
U.ST2 


Unit status 


Physical unit no. 


U.CW1 


Characteristics word 1 


U.CW2 


Characteristics word 2 


U.CW3 


Characteristics word 3 


U.CW4 


Characteristics word 4 


U.SCB 


Pointer to SCB 


U.ATT 


TCB address of attached task 


U.BUF 


Buffer relocation bias 


U.BUF+2 


Buffer address 


U.CNT 


Byte count 




Device- 




dependent 





2 

4 

6 

10 

12 

14 

16 

20 

22 

24 

26 

30 



32 



All 
devices 



storage 



1. This offset appears only in multiuser systems. 

2. These offsets appear only for terminal devices (that is, those devices that have DV.TTY 
set) in multiuser systems. 

3. This offset appears only for terminal devices in multiuser systems that include alternate 
CLI support. In multiuser systems without alternate CLI support, this offset has a symbolic 
name of U.CLI. See descriptions and note in text. 

4. These offsets appear only for mass storage devices (those devices that have DV.MSD set) 
in systems that employ error-logging. 

5. These offsets are device-dependent. 

ZK-225-81 

Figure 4-5 Unit Control Block 
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U.OWN (initialize to zero) 

Driver access: 

Initialized, not referenced. 

Description: 

In multiuser systems only: the UCB address of the owning 
terminal for allocated devices. 

U.DCB (pointer to associated DCB) 

Driver access: 

Initialized, not referenced. 

Description: 

Backpointer to the corresponding DCB. Because the UCB is a 
key control block in the I/O data structure, access to other 
control blocks usually occurs by means of links implanted in 
the UCB. 

U.RED (redirect pointer — initialized to point to U.DCB of the UCB) 

Driver access: 

Initialized, not referenced. 

Description: 

Contains a pointer to the UCB to which this device-unit has 
been redirected. This field is updated as the result of an 
MCR Redirect command. The redirect chain ends when this word 
points to the beginning of the UCB itself (U.DCB of the UCB 
to be precise) . 

U.CTL (set by you) 

Driver access: 

Initialized, not referenced. 

Description: 

U.CTL and the function mask words in the DCB drive QIO 
directive processing. You are responsible for setting up 
this bit pattern. Any inaccuracy in the bit setting of U.CTL 
produces erroneous I/O processing. Bit symbols and their 
meanings are as follows: 

UC.ALG - Alignment bit. 

If this bit equals 0, then byte alignment of data buffers 
is allowed. If UC.ALG equals 1, then buffers must be 
aligned on word boundaries. 

UC.ATT - Attach/Detach notification. 

If this bit is set, then the driver is called when $GTPKT 
processes an Attach/Detach I/O function. Typically, the 
driver does not need to obtain control for Attach/Detach 
requests, and the Executive performs the entire function 
without any assistance from the driver. 
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UC.KIL - Unconditional Cancel I/O call bit. 

If set, the driver is called on a Cancel I/O request, 

even if the unit specified is not busy. Typically, the 

driver is called on Cancel I/O only if an I/O operation 
is in progress. 

UC.QUE - Queue bypass bit. 

If set, the QIO directive processor calls the driver 
prior to queuing the I/O packet. After the processor 
makes this call, the driver is responsible for the 
disposition of the I/O packet. Typically, the processor 
queues an I/O packet prior to calling the driver, which 
later retrieves it by a call to $GTPKT. 

UC.PWF - Unconditional call on power failure bit. 

If set and the unit is on line, the driver is always to 
be called when the system is bootstrapped or power is 
restored after a power failure occurs. Typically, the 
driver is called on power restoration only when an I/O 
operation is in progress. Additionally, for loadable 
drivers, the driver is called when loaded if the unit is 
on line and UC.PWF is set. 

UC.NPR - NPR device bit. 

If set, the device is an NPR device. This bit determines 
the format of the 2-word address in U.BUF (details given 
in the discussion of U.BUF below) . 

UC.LGH - Buffer size mask bits (2 bits). 

These two bits are used to check whether the byte count 
specified in an I/O request is a legal buffer modulus. 
You select one of the values below by ORing into the byte 
a 0, 1, or 3. 

00 - Any buffer modulus valid 

01 - Must have word alignment modulus 

10 - Combination invalid 

11 - Must have doubleword alignment modulus 

UC.ALG and UC.LGH are independent settings. 

UC.ATT, UC.KIL, UC.QUE, and UC.PWF are usually zero, 
especially for conventional drivers. Every driver, however, 
must be concerned with its particular values for UC.ALG, 
UC.NPR, and UC.LGH. You are totally responsible for the 
values in these bits, and erroneous values are likely to 
produce unpredictable results. 

U.STS (initialize to zero) 

Driver access: 

Initialized, not referenced. 
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Description: 

This byte contains device-independent status information. 
The bit meanings are as follows: 

US.BSY - If set, device-unit is busy. 

US.MNT - If set, volume is not mounted. 

US. FOR - If set, volume is foreign. 

US.MDM - If set, device is marked for dismount. 

The unused bits in U.STS are reserved for system use and 
expansion. US.MDM, US.MNT, and US. FOR apply only to 
mountable devices. 

U.UNIT (unit number) 

Driver access: 

Initialized, read-only. 

Description : 

This byte contains the physical unit number of the 
device-unit (that is, the value required for the hardware to 
access the specified drive unit) . If the controller for the 
device supports only a single unit, the unit number is always 
zero. 

U.ST2 (set by you) 

Driver access: 

Initialized, not referenced. 

Description: 

This byte contains additional device-independent status 
information. The bit meanings are as follows: 

US.OFL - If set, the device is off line (that is, not in 
the configuration) . 

US. RED - If set, the device cannot be redirected. 

US. PUB - If set, the device is a public device. 

US.UMD - If set, the device is attached for diagnostics. 

The remaining bits are reserved for system use and expansion. 

U.CW1 (set by you) 

Driver access: 

Initialized, not referenced. 
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Description: 

The first of a 4-word contiguous cluster of device 
characteristics information. U.CW1 and U.CW4 are device 
independent. U.CW2 and U.CW3 are device dependent. The four 
characteristics words are retrieved from the UCB and placed 
in the requester's buffer on issuance of a Get LUN 
information (GLUN$) Executive directive. It is your 
responsibility to supply the contents of these four words in 
the assembly source code of the driver's data structure. 

U.CW1 is defined as follows (If a bit is set to 1, the 
corresponding characteristic is true for the device.): 

DV. REC Bit — Record-oriented device 

DV. CCL Bit 1 — Carriage-control device 

DV. TTY Bit 2 — Terminal device 

DV.DIR Bit 3 — Directory device 

DV.SDI Bit 4 — Single directory device 

DV. SQD Bit 5 — Sequential device 

DV.MSD Bit 6 — Mass storage device 

DV.UMD Bit 7 — Device supports user-mode diagnostics 

DV. EXT Bit 8— Device attached to a 22-bit direct addressing 

controller 

DV. SWL Bit 9 — Unit is software wr ite-locked 

DV. ISP Bit 10 — Input spooled device 

DV. OSP Bit 11 — Output spooled device 

DV. PSE Bit 12 — Pseudo device 

DV.COM Bit 13 — Device mountable as a communications channel 

DV. Fll Bit 14 — Device mountable as a Files-11 device 

DV.MNT Bit 15 — Device mountable 

U.CW2 (initialize to zero) 

Driver access: 

Initialized, read-write. 

Description : 

Specific to a given device driver (available for working 
storage or constants) .1 

U.CW3 (initialize to zero) 

Driver access: 

Initialized, read-write. 

Description : 

Specific to a given device driver (available for working 
storage or constants) .1 



1. Exception: for block-structured devices, U.CW2 and U.CW3 cannot be 
used for working storage. In drivers for block-structured devices 
(disks and DECtape) , these two words must be initialized to a 
double-precision number giving the total number of blocks on the 
device. Place the high-order bits in the low-order byte of U.CW2 and 
the low-order bits in U.CW3. 
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For tape UCBs , the high and low bytes of this word specify 
the highest and lowest densities, respectively, supported by 
the device. Symbolic names for U.CW3 are defined as follows 
for tape UCBs: 

UN.UNS Unsupported/unspecified 

UD.200 200 bits/in, 7-track 

UD.556 556 bits/in, 7-track 

UD.800 800 bits/in, 7- or 9-track 

UD.160 1600 bits/in, 9-track 

UD.625 6250 bits/in, 9-track 

For example, a TE16 tape drive supports densities of both 800 
and 1600 bits/in. For a TE16 drive, U.CW3 would be coded as 
follows: 

.BYTE UD.800, UD.160 

U.CW4 (set by you) 

Driver access: 

Initialized, read-only. 

Description : 

Default buffer size. This word is changed by the MCR command 
SET /BUF. 

U.SCB (SCB pointer) 

Driver access: 

Initialized, read-only. 

Description : 

This field contains a pointer to the SCB for this UCB. In 
general, R4 contains the value in this word when the driver 
is entered by way of the driver dispatch table, because 
service routines frequently reference the SCB. 

U.ATT (initialize to zero) 

Driver access: 

Initialized, not referenced. 

Description : 

If a task has attached itself to the device-unit, this field 
contains its TCB address. 

U.BUF (reserve two words of storage) 

Driver access: 

Not initialized, read-write. 
Description: 

U.BUF labels two consecutive words that serve as a 
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U.BUF+2, and U.CNT receive the first three words from the I/O 
packet . 
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For transfer operations, the format of these two words 
depends on the setting of UC.NPR in U.CTL. The driver does 
not format the words; all formatting is completed before the 
driver receives control. For unmapped systems, the first 
word is zero, and the second word is the physical address of 
the buffer. For mapped systems, the format is determined by 
the UC.NPR bit, which is set for an NPR device and reset for 
a program transfer device. 

The format for program transfer devices is identical to that 
for the second two words of I.IOSB in the I/O packet. See 
Section 4.1.1.1. 

In general, the driver does not manipulate these words when 
performing I/O to a program transfer device. Instead, it 
uses the Executive routines Get Byte, Get Word, Put Byte, and 
Put Word to effect data transfers between the device and the 
user's buffer. 

For NPR device drivers, the word layout is as follows: 
Word 1 

Bit Go bit initially set to zero 

Bits 1-3 Function code — set to zeros 

Bits 4,5 Memory extension bits 

Bits 6 Interrupt enable — set to zero 

Bits 7-15 Zero 

Word 2 

Bits 0-15 Low-order 16-bits of physical address 

It is your responsibility to set the function code, interrupt 
enable, and go bits. This action must be accomplished by a 
Bit Set (BIS) instruction so that the extension bits are not 
disturbed. The driver must move these words into the device 
control registers to initiate the I/O operation. 

Note that when the system is unmapped, bits 4 and 5 are 

always zero, but this fact is transparent to the driver. 

Thus, NPR device drivers are not cognizant of the mapping 
state in the system. 

The construction of U.BUF, U.BUF+2, and U.CNT occurs only if 
the requested function is a transfer function; if it is not, 
these three words contain the first three words of the I/O 
packet. 

The details of the construction of the address doubleword 
appear in Appendix A. 

U.CNT (reserve 1 word of storage) 

Driver access: 

Not initialized, read-write. 

Description : 

Contains the byte count of the buffer described by U.BUF. 
The driver uses this field in constructing the actual device 
request. 
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U.BUF and U.CNT keep track of the current data item in the 
buffer for the current transfer (except for NPR transfers) . 
Because this field is being altered dynamically, the I/O 
packet may be needed to reissue an I/O operation, for 
instance, after a powerfail or error retry. 

Device-Dependent Words: 

Driver access: 

Not initialized, read-write. 

Description: 

You establish this variable-length block of words to suit 
device-specific requirements. 



4.1.5 The Device Interrupt Vector 

For resident drivers only, the device interrupt vector must be 
initialized when defining data structures, and must not be altered 
dynamically. This practice makes the driver code independent of 
device register address assignments and of the actual location of the 
interrupt vector. The driver data structure must include a storage 
assignment and initialization for the interrupt vector with the 
priority set to PR7. See lines 81 through 85 in Section 6.2.1 
(Section 6.2.1 contains the source code for the data structure of a 
sample resident driver) . 

Writers of loadable drivers do not initialize the device interrupt 
vector. The vector is dynamically established by the MCR LOA command 
when the driver is loaded. When a driver is unloaded, the MCR UNL 
command sets the vector to the system nonsense interrupt entry point. 



4.2 MULTICONTROLLER DRIVERS 

This section discusses the conditional code needed at the interrupt 

entry point of a driver that may handle one or several device 

controllers. This discussion leads to a description in the next 

section of the system macro INTSV$. INTSV$ contains multicontroller 

conditionals and other features to simplify interrupt entry coding. 

Figure 4-6 shows the interrupt entry coding from the paper-tape-punch 
driver. This is an earlier version of the driver presented in its 
entirety in Section 6.2.2. 

The coding is conditional ized on P$$P11-1. The symbol P$$P11 
represents the number of controllers and is set at SYSGEN. 

In a multicontroller device configuration, the controllers are 
numbered starting with 0. The code for a multicontroller driver 
contains a table (called CNTBL in the example in Figure 4-6) whose 
length in words is equal to the number of controllers. A number 
called the controller index — equal to the controller number times 
2 — is stored in the SCB for each controller, in byte S.CON. 

When an I/O request occurs, and the driver is called at its initiator 
entry point, the driver first calls $GTPKT to obtain an I/O packet to 
process. Among the values returned by $GTPKT are the controller index 
(obtained from S.CON in the SCB) and the address of the UCB for the 
unit requesting I/O service. 
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The driver stores the requesting unit's UCB address in the controller 
table (CNTB1) at an offset equal to the controller index. Thus, for 
the driver at its interrupt entry point to access the requesting UCB, 
it needs simply to obtain the controller index. 
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For single-controller devices, CNTBL is one word, TEMP is not needed 
to store the PS, and the UCB address is always the first (and only) 
entry in CNTBL. 



NOTE 

The code sequence used in the following 
example is not valid for a loadable 
driver. 



1 ; + 

2 ; **-$PPINT-PCll PAPER TAPE PUNCH CONTROLLER INTERRUPTS 

3 ?- 



5 $PPINT:: 




6 






7 


.IF GT 


P$$P11-1 


8 






9 


MOV 


PS, TEMP 


10 






11 


. IFTF 




12 






13 


CALL 


$INTSV,PR4 


14 






15 


. IFT 




16 






17 


MOV 


TEMP,R4 


18 


BIC 


#177760, R4 


19 


ASL 


R4 


20 


MOV 


CNTBL (R4) ,R5 


21 






22 


.IFF 




23 






24 


MOV 


CNTBL, R5 


25 






26 


.ENDC 





; ; ;REF LABEL 



;;;SAVE CONTROLLER NUMBER 



;;;SAVE REGISTERS AND SET PRIORITY 



RETRIEVE CONTROLLER NUMBER 
CLEAR ALL BUT CONTROLLER NUMBER 
CONVERT TO CONTROLLER INDEX 
RETRIEVE ADDRESS OF UCB 



;;; RETRIEVE ADDRESS OF UCB 



Figure 4-6 Conditional Code for a Multicontroller Driver 



4-34 



WRITING AN I/O DRIVER— PROGRAMMING SPECIFICS 

4.3 THE INTSV$ MACRO 

INTSV$ is a system macro that minimizes coding differences between 
loadable and resident drivers. INTSV$ contains conditionally 
assembled code to handle: 

• Single or multiple controllers 

• Loadable or resident drivers 

• Mapped or unmapped systems 

You can replace all the code in Figure 4-6 between lines 7 and 26 with 
the INTSV$ macro (as is done in the sample driver illustrated in 
Section 6.2.2). This is required for loadable drivers on mapped 
systems, because interrupts from hardware devices must be processed in 
kernel address space. In particular, the decoding of the PS word and 
the call to $INTSV must be done before entering the driver. Thus, a 
call to the Executive routine $INTSV within a loadable driver is 
illegal, and the MCR LOA function returns an error if loading is 
attempted. 

When the INTSV$ macro is used for a loadable driver in a mapped 
system, the code from lines 9 to 19 inclusive (Figure 4-6) is not 
assembled as part of the driver. Instead, the LOA function allocates 
a block of dynamic memory in kernel address space to contain the 
interrupt coding. This block, called the Interrupt Control Block 
(ICB) , also contains coding to perform the following: 

1. Save the kernel mapping (APR5) 

2. Load APR5 to map the driver 

3. Transfer to the driver 

4. Restore the mapping after return 

The LOA function also sets up the controller's interrupt vector so 
that hardware interrupts point to the ICB. 

Finally, using the INTSV$ macro in a loadable driver on a mapped 
system requires that the symbol LD$xx (where xx is the 2-character 
device mnemonic) be defined either in the driver source or the 
assembly prefix file RSXMC.MAC. 



4.3.1 Format 

The format of the INTSV$ macro is: 

INTSV$ xx,pri,nctlr [ ,pssave,ucbsave] 
xx 

The 2-character device mnemonic, 
pri 

The priority of the device (the priority that would be used in a 
call to $INTSV). 
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nctlr 

The number of controllers the driver services. 



pssave 



An optional argument specifying a variable in which to save the 
PS word. If omitted, a variable named TEMP is used. 

ucbsave 

An optional argument specifying a block of contiguous words in 
which to retrieve the interrupting device's UCB address. If 
omitted, a block of contiguous words named CNTBL is used. 

Outputs: R4 is the controller index, only if nctlr is greater than 

1. 

R5 is the UCB address. 

Example: 

INTSV$ PP,PR4,P$$P11 

This usage of INTSV$ would effectively replace lines 7 through 26 in 
Figure 4-6. (P$$P11 is a symbol equated to the number of 

controllers.) 
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CHAPTER 5 
EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



This section contains the Executive routines typically used by I/O 
drivers. They are listed in alphabetical order. The descriptions are 
taken directly from the source code for the associated services. 

We describe only the most widely used subroutines. Many other 
Executive service subroutines are available in modules IOSUB.MAC, 
EXESB.MAC, MEMAP.MAC, SYSXT.MAC, QUEUE. MAC, CORAL. MAC, and REQSB.MAC 
in UFD [11,10] . 



5.1 SYSTEM STATE REGISTER CONVENTIONS 

In system state, R5 and R4 are, by convention, nonvolatile registers. 
This means that an internally called routine is required to save and 
restore these two registers if the routine destroys their contents. 
R3, R2, Rl, and R0 are volatile registers and may be used by a called 
routine without save and restore responsibilities. 

When a driver is entered directly from an interrupt, it is operating 

at interrupt level, not at system state. At interrupt level, any 

register the driver uses must be saved and restored. INTSV$ preserves 
R5 and R4 for the driver's use. 

A routine may violate these conventions as long as an explicit 
statement exists in the program preface detailing the departure from 
conventions. Such departures should generally be avoided; they 
should be employed only when you can demonstrate that a departure from 
convention can improve overall system performance. 

See D.DSP in Section 4.1.2.1 for the contents of registers when a 
driver is entered. 



5.2 CONDITIONAL ROUTINES 

Two of the routines ($GTWRD and $PTWRD) discussed in this chapter 
normally are assembled conditionally out of the Executive code. If a 
user-written driver requires either of these routines, the appropriate 
question must be answered affirmatively in the system generation 
dialog. See the descriptions of $GTWRD and $PTWRD below. 



5. 3 SERVICE CALLS 

In the following descriptions, the file names mentioned are source 
modules found on the Executive source disk as [11, 10] f ilnam.MAC. 
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$ACHKB/$ACHCK 



ADDRESS CHECK 

These routines are in the file EXESB. A driver may call either 
routine to address-check a task buffer while the task is the current 
task. The $ACHKB and $ACHCK routines are normally used only by 
drivers setting UC.QUE in U.CTL. See Section 6.3 for an example. 

Calling sequences: 

CALL $ACHKB 

or 

CALL $ACHCK 

Description: 

+ 
**-$ACHKB-ADDRESS CHECK BYTE ALIGNED 
**-$ACHCK-ADDRESS CHECK WORD ALIGNED 

THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE 
WHETHER IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK. 



INPUTS: 



RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED. 
R1=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES. 



OUTPUTS: 



C=l IF ADDRESS CHECK FAILED. 
C=0 IF ADDRESS CHECK SUCCEEDED. 

RO AND R3 ARE PRESERVED ACROSS CALL. 
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$ALOCB 



ALLOCATE CORE BUFFER 

This routine is in the file CORAL. 

Calling sequences: 

CALL $ALOCB 
or 

CALL $ALOCl 

+ 
**-$ALOCB-ALLOCATE CORE BUFFER 
**-$ALOCl-ALLOCATE CORE BUFFER (ALTERNATE ENTRY) 

THIS ROUTINE IS CALLED TO ALLOCATE AN EXEC CORE BUFFER. THE 
ALLOCATION ALGORITHM IS FIRST FIT AND BLOCKS ARE ALLOCATED IN 
MULTIPLES OF FOUR BYTES. 



INPUTS: 



RO=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT $ALOCl. 
R1=SIZE OF THE CORE BUFFER TO ALLOCATE IN BYTES. 



OUTPUTS: 



C=l IF INSUFFICIENT CORE IS AVAILABLE TO ALLOCATE THE BLOCK. 
C=0 IF THE BLOCK IS ALLOCATED. 

RO=ADDRESS OF THE ALLOCATED BLOCK. 

R1=LENGTH OF BLOCK ALLOCATED. 
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SASUMR 



ASSIGN UNIBUS MAPPING REGISTERS 

This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/O driver. 
Rather, it is called from within the $STMAP routine. Refer to 
Appendix B for a discussion. 

Calling sequence: 

CALL $ASUMR 

Description: 

+ 
**-$$ASUMR-ASSIGN UNIBUS MAPPING REGISTERS 

THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR'S. NOTE THAT 
FOR THE SAKE OF SPEED, THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK 
POINTS TO THE UMR ADDRESS (2ND) WORD OF THE BLOCK, NOT THE FIRST WORD. 
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF 
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE 
FIRST UMR ASSIGNED AND THE NUMBER OF UMR'S ASSIGNED TIMES 4. THE 
BLOCKS ARE LINKED IN THE ORDER OF INCREASING FIRST UMR ADDRESS. 

INPUTS: 

R0=POINTER TO A MAPPING REGISTER ASSIGNMENT BLOCK. 
M.UMRN(RO)=NUMBER OF UMR'S REQUIRED * 4. 

OUTPUTS: 

ALL REGISTERS ARE PRESERVED. 

C=0 IF THE UMR'S WERE SUCCESSFULLY ASSIGNED. 

ALL FIELDS OF THE MAPPING REGISTER ASSIGNMENT BLOCK 

ARE INITIALIZED AND THE BLOCK IS LINKED INTO 

THE ASSIGNMENT LIST. 
C=l IF THE UMR'S COULD NOT BE ASSIGNED. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

SCLINS 



CLOCK QUEUE INSERTION 

This routine is in the file QUEUE. 

Calling sequence: 

CALL $CLINS 

Description: 

+ 
**-$CLINS-CLOCK QUEUE INSERTION 

THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. THE ENTRY 
IS INSERTED SUCH THAT THE CLOCK QUEUE IS ORDERED IN ASCENDING TIME. 
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST. 



INPUTS: 



RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK. 

R1=HIGH ORDER HALF OF DELTA TIME. 

R2=LOW ORDER HALF OF DELTA TIME. 

R4=REQUEST TYPE. 

R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER. 



OUTPUTS: 



THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING 
TO THE TIME THAT IT WILL COME DUE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$DEACB 



DEALLOCATE CORE BUFFER 
This routine is in the file CORAL. 
Calling sequences: 
CALL $DEACB 



or 



CALL $DEAC1 



**-$DEACB-DEALLOCATE CORE BUFFER 
**-$DEACl-DEALLOCATE CORE BUFFER (ALTERNATE ENTRY) 

THIS ROUTINE IS CALLED TO DEALLOCATE AN EXEC CORE BUFFER. THE BLOCK 
IS INSERTED INTO THE FREE BLOCK CHAIN BY CORE ADDRESS. IF AN 
ADJACENT BLOCK IS CURRENTLY FREE, THEN THE TWO BLOCKS ARE MERGED 
AND INSERTED IN THE FREE BLOCK CHAIN. 

INPUTS: 

RO=ADDRESS OF THE CORE BUFFER TO BE DEALLOCATED. 
R1=SIZE OF THE CORE BUFFER TO DEALLOCATE IN BYTES. 
R3=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT $DEAC1. 



OUTPUTS: 



THE CORE BLOCK IS MERGED INTO THE FREE CORE CHAIN BY CORE 
ADDRESS AND IS MERGED IF NECESSARY WITH ADJACENT BLOCKS. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$DEUMR 



DEASSIGN UNIBUS MAPPING REGISTERS 

This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/O driver. 
Rather, it is called from within the $IODON routine. Refer to 
Appendix B for a discussion., 

Calling sequence: 

CALL $DEUMR 

Description: 

+ 
**-$DEUMR-DEASSIGN UNIBUS MAPPING REGISTERS 

THIS ROUTINE IS CALLED TO DEASSIGN A CONTIGUOUS BLOCK OF UMR'S. IF 
THE MAPPING ASSIGNMENT BLOCK IS NOT IN THE LIST, NO ACTION IS TAKEN. 
NOTE THAT FOR THE SAKE OF ASSIGNMENT SPEED, THE LINK WORD POINTS TO 
THE UMR ADDRESS (2ND) WORD OF THE ASSIGNMENT BLOCK. 

INPUTS: 

R2=POINTER TO ASSIGNMENT BLOCK. 

OUTPUTS: 

RO AND Rl ARE PRESERVED. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$DVMSG 



DEVICE MESSAGE OUTPUT 

This routine is in file EXESB. 

Calling sequence: 

CALL $DVMSG 

Description: 

+ 
**-$DVMSG-DEVICE MESSAGE OUTPUT 

THIS ROUTINE IS CALLED TO SUBMIT A MESSAGE TO THE TASK TERMINATION 
NOTIFICATION TASK. MESSAGES ARE EITHER DEVICE RELATED OR A 
CHECKPOINT WRITE FAILURE FROM THE LOADER. 

INPUTS: 

RO=MESSAGE NUMBER. 

R5=ADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO. 



OUTPUTS: 



A FOUR WORD PACKET IS ALLOCATED, RO AND R5 ARE STORED IN THE 
SECOND AND THIRD WORDS, RESPECTIVELY, AND THE PACKET IS 
THREADED INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE 
QUEUE. 

NOTE: IF THE TASK TERMINATION NOTIFICATION TASK IS NOT 

INSTALLED OR NO STORAGE CAN BE OBTAINED, THEN THE 
MESSAGE REQUEST IS IGNORED. 



Note : 



Drivers use only two codes in calling $DVMSG: T.NDNR (device not 
ready) , and T.NDSE (select error) . $DVMSG can be set up and 
called as follows: 

MOV #T.NDNR,R0 

or 

MOV #T.NDSE,R0 
CALL $DVMSG 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$EXRQP 



EXECUTIVE REQUEST WITH QUEUE INSERT BY PRIORITY 

This routine is in the file REQSB. $EXRQP requests the execution of a 
task after inserting a packet into the receive list of the task. 

Calling sequence: 

CALL $EXRQP 

Description: 



**-$EXRQP-EXECUTIVE REQUEST WITH QUEUE INSERT BY PRIORITY 
**-$EXRQF-EXECUTIVE REQUEST WITH QUEUE INSERT FIFO 
**-$EXRQN -EXECUTIVE REQUEST WITH NO QUEUE INSERTION 
**-$EXRQU-EXECUTIVE UNSTOP AND REQUEST WITH NO QUEUE INSERTION 
**-$EXRQS-EXECUTIVE REQUEST WITH NO CONDITIONAL SCHEDULE REQUEST 

THESE ROUTINES PROVIDE A STANDARD INTERFACE TO ALL TASKS REQUESTED BY 
THE EXECUTIVE 



INPUTS: 



R0=TCB ADDRESS OF TASK TO REQUEST 

R1=ADDR OF PACKET TO QUEUE TO TASK (IF ENTRY AT $EXRQP/$EXRQF) 



OUTPUTS: 



C=0 IF THE REQUEST WAS SUCCESSFULLY COMPLETED. 
C=l IF THE TASK WAS NOT SUCCESSFULLY REQUESTED. 

Z=0 IF PCB ALLOCATION FAILURE. 

Z=l IF TASK ACTIVE, BEING REMOVED, OR BEING FIXED. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$FORK 



FORK 

This routine is in the file SYSXT. A driver calls $FORK to switch 
from a partially interruptable level (its state following a call on 
$INTSV) to a fully interruptable level. 

Cabling sequence: 

CALL $FORK 

Description: 

+ 
**-$FORK-FORK AND CREATE SYSTEM PROCESS 

THIS ROUTINE IS CALLED FROM AN I/O DRIVER TO CREATE A SYSTEM PROCESS THAT 
WILL RETURN TO THE DRIVER AT STACK DEPTH ZERO TO FINISH PROCESSING. 

INPUTS: 

R5=ADDRESS OF THE UCB FOR THE UNIT BEING PROCESSED. 

OUTPUTS: 

REGISTERS R5 AND R4 ARE SAVED IN THE CONTROLLER FORK BLOCK AND 
A SYSTEM PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK 
QUEUE AND A JUMP TO $INTXT IS EXECUTED. 



Notes; 



1. $FORK cannot be called unless $INTSV has been previously 
called. The fork-processing routine assumes that $INTSV has 
set up entry conditions. 

2. A driver's current time-out count is cleared in calls to 
$FORK. This protects the driver from synchronization 
problems that can occur when an I/O request and the time-out 
for that request happen at the same time. After a return 
from a call to $FORK, a driver's time-out code will not be 
entered . 

If the clearing of the time-out count is not desired, a 
driver has two alternatives: 

a. Perform time-out operations by directly inserting 
elements in the clock queue (refer to the description of 
the $CLINS routine) . 

b. Perform necessary initialization, including clearing 
S.STS in the SCB to zero (establishing the controller as 
not busy) , and call the $F0RK1 routine rather than $FORK. 
Calling $F0RK1 bypasses the clearing of the current 
time-out count. 

3. The driver must not have any information on the stack when 
$FORK is called. 



5-10 



EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$FORK1 



FORKl 

This routine is in the file SYSXT. A driver calls $FORKl to bypass 

the clearing of its time-out count when it switches from a partially 

interruptable level to a fully interruptable level (refer also to the 
description of the $FORK routine) . 

Calling sequence: 

CALL $F0RK1 

Description: 

+ 
**-$FORKl-FORK AND CREATE SYSTEM PROCESS 

THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND 
SAVE REGISTER R5. 



INPUTS: 



R4=ADDRESS OF THE LAST WORD OF A 3 WORD FORK BLOCK PLUS 2. 
R5=REGISTER TO BE SAVED IN THE FORK BLOCK. 



OUTPUTS: 



REGISTER R5 IS SAVED IN THE SPECIFIED FORK BLOCK AND A SYSTEM 
PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK QUEUE 
AND A JUMP TO $INTXT IS EXECUTED. 



Notes: 



1. For mapped systems with loadable driver support, a 5-word 
fork block is required for calls to $F0RK1. 

2. When a 5-word fork block is used, the driver must initialize 
the fifth word with the base address (in 32-word blocks) of 
the driver partition. This address can be obtained from the 
fifth word of the standard fork block in the SCB. 

3. The driver must not have any information on the stack when 
$F0RK1 is called. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$GTBYT 



GET BYTE 

This routine is in the file BFCTL. $GTBYT manipulates words U.BUF and 
U.BUF+2 in the UCB. 

Calling sequence: 

CALL $GTBYT 

Description: 

+ 
**-$GTBYT-GET NEXT BYTE FROM USER BUFFER 

THIS ROUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE BYTE HAS BEEN 
FETCHED, THE NEXT BYTE ADDRESS IS INCREMENTED. 

INPUTS: 

R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 

OUTPUTS: 

THE NEXT BYTE IS FETCHED FROM THE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK. THE NEXT BYTE ADDRESS IS 
INCREMENTED. 

ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$GTPKT 



GET PACKET 

This routine is in the file IOSUB. 
Calling sequence: 
CALL $GTPKT 

+ 

**-$GTPKT-GET I/O PACKET FROM REQUEST QUEUE 

THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O 
REQUEST TO PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY 
SET INDICATION IS RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO 
DEQUEUE THE NEXT REQUEST FROM THE CONTROLLER QUEUE. IF NO REQUEST 
CAN BE DEQUEUED, THEN A CARRY SET INDICATION IS RETURNED TO THE 
CALLER. ELSE THE CONTROLLER IS SET BUSY AND A CARRY CLEAR 
INDICATION IS RETURNED TO THE CALLER. 

INPUTS: 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO GET A PACKET FOR. 

OUTPUTS: 

C=l IF CONTROLLER IS BUSY OR NO REQUEST CAN BE DEQUEUED. 
C=0 IF A REQUEST WAS SUCCESSFULLY DEQUEUED. 

R1=ADDRESS OF THE I/O PACKET. 

R2=PHYSICAL UNIT NUMBER. 

R3=CONTROLLER INDEX. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 

R5=ADDRESS OF THE UNIT CONTROL BLOCK. 

NOTE: R4 AND R5 ARE DESTROYED BY THIS ROUTINE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$GTWRD 



GET WORD 

This routine is in the file BFCTL. $GTWRD manipulates words U.BUF and 
U.BUF+2 in the UCB, and is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN when the following question is asked: 

*26. Include routine $GTWRD? [Y/N]: 

If an LPA11 device (LA:) is included in your system, the $GTWRD 
routine is automatically included and Question 26 is not asked. 

Calling sequence: 

CALL $GTWRD 

Description: 

+ 
**-$GTWRD-GET NEXT WORD FROM USER BUFFER 

THIS ROUTINE IS CALLED TO GET THE NEXT WORD FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE WORD HAS BEEN 
FETCHED, THE NEXT WORD ADDRESS IS CALCULATED. 

INPUTS: 

R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 

OUTPUTS: 

THE NEXT WORD IS FETCHED FROM THE USER BUFFER AND RETURNED 

TO THE CALLER ON THE STACK. THE NEXT WORD ADDRESS IS CALCULATED. 

ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$INTSV 



INTERRUPT SAVE 

This routine is in the file SYSXT. 

Calling sequence: 

CALL $INTSV,PRn 



11 tjao a Laii^c u J- u / ■ 



Description: 

f. 
**-$!NTSV-INTERRUPT SAVE 

THIS ROUTINE IS CALLED FROM AN INTERRUPT SERVICE ROUTINE WHEN AN 
INTERRUPT IS NOT GOING TO BE IMMEDIATELY DISMISSED. A SWITCH TO 
THE SYSTEM STACK IS EXECUTED IF THE CURRENT STACK DEPTH IS +1. WHEN 
THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS, 
JUMPS TO $INTXT, OR EXECUTES A RETURN. 



INPUTS: 



4(SP)=PS WORD PUSHED BY INTERRUPT. 
2(SP)=PC WORD PUSHED BY INTERRUPT. 
0(SP)=SAVED R5 PUSHED BY 'JSR R5,$INTSV 
0(R5)=NEW PROCESSOR PRIORITY. 



OUTPUTS: 



REGISTER R4 IS PUSHED ONTO THE CURRENT STACK AND THE CURRENT 
STACK DEPTH IS DECREMENTED. IF THE RESULT IS ZERO, THEN 
A SWITCH TO THE SYSTEM STACK IS EXECUTED. THE NEW PROCESSOR 
STATUS IS SET AND A CO-ROUTINE CALL TO THE CALLER IS EXECUTED. 



Note : 



A system macro, INTSV$, is provided to simplify the coding of 
standard interrupt entry processing. See Section 4.3. 



5-15 



EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$INTXT 

INTERRUPT EXIT 

This routine is in the file SYSXT. 

Calling sequence: 

JMP $INTXT 
or 

RETURN (if a call to $INTSV has been executed) 

Description: 

+ 
**-$INTXT-INTERRUPT EXIT 

THIS ROUTINE IS CALLED VIA A RETURN TO EXIT FROM AN INTERRUPT. IF THE 

STACK DEPTH IS NOT EQUAL TO ZERO, THEN REGISTERS R4 AND R5 ARE 

RESTORED AND AN RTI IS EXECUTED. ELSE A CHECK IS MADE TO SEE 

IF THERE ARE ANY ENTRIES IN THE FORK QUEUE. IF NONE, THEN R4 AND 

R5 ARE RESTORED AND AN RTI IS EXECUTED. ELSE REGISTERS R3 THRU 

RO ARE SAVED ON THE CURRENT STACK AND A DIRECTIVE EXIT IS EXECUTED. 

INPUTS: (MAPPED SYSTEM) 

06(SP)=PS WORD PUSHED BY INTERRUPT. 
04(SP)=PC WORD PUSHED BY INTERRUPT. 
02(SP)=SAVED R5. 
00(SP)=SAVED R4. 

INPUTS: (REAL MEMORY SYSTEM) 

NONE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$IOALT/$IODON 



I/O DONE ALTERNATE ENTRY and I/O DONE 

These routines are in the file IOSUB. 

Calling sequences: 

CALL $IOALT 
CALL $IODON 

Description: 

+ 
**-$IOALT-I/0 DONE (ALTERNATE ENTRY) 
**-$IODON-I/0 DONE 

THIS ROUTINE IS CALLED BY DEVICE DRIVERS AT THE COMPLETION OF AN I/O REQUEST 
TO DO FINAL PROCESSING. THE UNIT AND CONTROLLER ARE SET IDLE AND $IOFIN IS 
ENTERED TO FINISH THE PROCESSING. 

INPUTS: 

R0=FIRST I/O STATUS WORD. 

Rl=SECOND I/O STATUS WORD. 

R2=STARTING AND FINAL ERROR RETRY COUNTS IF ERROR LOGGING DEVICE. 

R5=ADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED. 

NOTE: IF ENTRY IS AT $IOALT, THEN Rl IS CLEARED TO SIGNIFY THAT THE 
SECOND STATUS WORD IS ZERO. 

OUTPUTS: 

THE UNIT AND CONTROLLER ARE SET IDLE. 

R3=ADDRESS OF THE CURRENT I/O PACKET. 

NOTE 

R4 is destroyed when either of these 
routines is called. The routines call 
$IOFIN, which destroys R4. 

These routines push the address of 
routine $DQUMR onto the stack before 
returning to the driver. This precludes 
the use of the stack for temporary data 
storage by drivers when calling these 
routines. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$IOFIN 

I/O FINISH 

This routine is in the file IOSUB. Most drivers do not call $IOFIN, 
but you should be aware that this routine is executed when a driver 
calls $IOALT or $IODON. A driver that references an I/O packet before 
it is queued (bit UC.QUE set — see Section 6.3 for an example) calls 
$IOFIN if the driver finds an error while preprocessing the I/O 
packet. 

Calling sequence: 

CALL $IOFIN 

Description: 

+ 
**-$IOFIN-I/0 FINISH 

THIS ROUTINE IS CALLED TO FINISH I/O PROCESSING IN CASES WHERE THE UNIT AND 
CONTROLLER ARE NOT TO BE DECLARED IDLE. 

INPUTS: 

R0=FIRST I/O STATUS WORD. 
R1=SEC0ND I/O STATUS WORD. 
R3=ADDRESS OF THE I/O REQUEST PACKET. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 

OUTPUTS: 

THE FOLLOWING ACTIONS ARE PERFORMED: 

1-THE FINAL I/O STATUS VALUES ARE STORED IN THE I/O STATUS BLOCK IF 
ONE WAS SPECIFIED. 

2-THE I/O REQUEST COUNT IS DECREMENTED. IF THE RESULTANT COUNT IS 
ZERO, THEN 'TS.RDN 1 IS CLEARED IN CASE THE TASK WAS 
STOPPED FOR I/O RUNDOWN. 

3-IF 'TS.CKR' IS SET; THEN IT IS CLEARED AND CHECKPOINTING OF THE 
TASK IS INITIATED. 

4-IF AN AST SERVICE ROUTINE WAS SPECIFIED, THEN AN AST IS QUEUED 
FOR THE TASK. ELSE THE I/O PACKET IS DEALLOCATED. 

5 -A SIGNIFICANT EVENT OR EQUIVALENT IS DECLARED. 

NOTE: R4 IS DESTROYED BY THIS ROUTINE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$MPUBM 



MAP UNIBUS TO MEMORY 

This routine is in the file MEMAP. $MPUBM is used only for NPR 
devices requiring UNIBUS Mapping Registers, when 22-bit memory 
addressing is enabled. See Appendix B for a discussion. 

Calling sequence: 

CALL $MPUBM 

Description: 

+ 
**-$MPUBM-MAP UNIBUS TO MEMORY 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEM- 
ORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. 



INPUTS: 



R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB. 

OUTPUTS: 

THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE TRANSFER 
ARE LOADED. 

NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$MPUB1 



MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 

This routine is in file MEMAP. It is used only for NPR devices that 
require UNIBUS Mapping Registers, support parallel operations, and 
have 22-bit memory addressing enabled. See Appendix B for a 
discussion of using this routine. 

Calling sequence: 

CALL $MPUB1 

Description: 

+ 
**-$MPUBl-MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN 
MEMORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. THIS ALTERNATE 
ENTRY POINT ALLOWS THE DRIVER TO SPECIFY A NON-STANDARD UMR MAPPING 
ASSIGNMENT BLOCK. 

INPUTS: 

RO=ADDRESS OF A UMR MAPPING ASSIGNMENT BLOCK 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 

OUTPUTS: 

THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE 
TRANSFER ARE LOADED 

NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$PTBYT 

PUT BYTE 

^BQP+rin^h^UcS.^ ^ ^"^ SPTBYT mani P ulates *rds U.BUF and 
Calling sequence: 

CALL $PTBYT 

Description: 

+ 
**-$PTBYT-PUT NEXT BYTE IN USER BUFFER 

THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN 

is E incremeSted! TER THE BYTE HAS BEEN ST0RED ' THE next byte address 



INPUTS: 



R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS 
2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER. 



OUTPUTS: 



THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK. THE NEXT BYTE ADDRESS IS INCREMENTED. 

ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$PTWRD 



PUT WORD 

This routine is in the file BFCTL. $PTWRD manipulates words U.BUF and 
U BUF+2 in the UCB. $PTWRD is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN to the following question: 

*27. Include routine $PTWRD? [Y/N]: 

If an AD01 A/D controller device (AF:) or an AFC11 A/D controller 
device (AF:) is included in your system, the $PTWRD routine is 
automatically included and Question 27 is not asked. 

Do you intend to include a user written driver? [Y/N]: 

Calling sequence: 

CALL $PTWRD 

Description: 

+ 
**-$PTWRD-PUT NEXT WORD IN USER BUFFER 

THIS ROUTINE IS CALLED TO PUT A WORD IN THE NEXT LOCATION IN 

USER BUFFER. AFTER THE WORD HAS BEEN STORED, THE NEXT WORD ADDRESS 

IS CALCULATED. 



INPUTS; 



R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
2(SP)=WORD TO BE STORED IN THE NEXT LOCATION OF THE BUFFER. 



OUTPUTS: 



THE WORD IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK. THE NEXT WORD ADDRESS IS CALCULATED. 

ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

$QINSP 



QUEUE INSERTION BY PRIORITY 

This routine is in the file QUEUE. A driver may call $QINSP to insert 
into the I/O queue an I/O packet that the Executive has not already 
placed in the queue. $QINSP is used only by drivers setting UC.QUE in 
U.CTL. See Section 6.3 for an example. 

Calling sequence: 

CALL $QINSP 

Description: 

+ 
**-$QINSP-QUEUE INSERTION BY PRIORITY 

THIS ROUTINE IS CALLED TO INSERT AN ENTRY IN A PRIORITY ORDERED 
LIST. THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A 
LOWER PRIORITY OR THE END OF THE LIST IS REACHED. THE NEW 
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT. 



INPUTS: 



RO=ADDRESS OF THE TWO WORD LISTHEAD. 
R1=ADDRESS OF THE ENTRY TO BE INSERTED. 



OUTPUTS: 

THE ENTRY IS LINKED INTO THE LIST BY PRIORITY. 
RO AND Rl ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$QRMVF 



QUEUE REMOVAL FROM FRONT OF LIST 

This routine is in the file QUEUE. 

Calling sequence: 

CALL $QRMVF 

Description: 

+ 
**-$QRMVG -QUEUE REMOVAL FROM FRONT OF LIST 

THIS ROUTINE IS CALLED TO REMOVE THE NEXT (FRONT) ENTRY FROM A 
LIST. THE LIST ORGANIZATION MAY BE EITHER FIFO OR BY PRIORITY. 

INPUTS: 

RO=ADDRESS OF THE TWO WORD LISTHEAD. 

OUTPUTS: 

C=l IF THERE ARE NO ENTRIES IN THE LIST. 

C=0 IF THE NEXT ENTRY IS REMOVED FROM THE LIST. 

R1=ADDRESS OF THE ENTRY REMOVED. 

RO IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 

SRELOC 



RELOCATE 

Relocate is in the file MEMAP. A driver may call $RELOC to relocate a 
task virtual address while the task is the current task. Relocate is 
normally used only by drivers setting UC.QUE in U.CTL. See Section 
6.3 for an example. 

Calling Sequence: 

CALL $RELOC 

Description: 

+ 
**-$RELOC -RELOCATE USER VIRTUAL ADDRESS 

THIS ROUTINE IS CALLED TO TRANSFORM A 16 BIT USER VIRTUAL ADDRESS 
INTO A RELOCATION BIAS AND DISPLACEMENT IN BLOCK RELATIVE TO APR6. 

INPUTS: 

R0=USER VIRTUAL ADDRESS TO RELOCATE. 

OUTPUTS: 

Rl=RELOCATION BIAS TO BE LOADED INTO PAR6. 

R2=D IS PLACEMENT IN BLOCK PLUS 140000 (PAR6 BIAS). 

R0 AND R3 ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 



$STMAP 



SET UP UNIBUS MAPPING ADDRESS 

This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. See Appendix B for a discussion. 

Calling sequence: 

CALL $STMAP 

Description: 

+ 
**-$STMAP-SET UP UNIBUS MAPPING ADDRESS 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO SET UP THE 
UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR'S. IF THE UMR'S 
CANNOT BE ALLOCATED, THE DRIVER'S MAPPING ASSIGNMENT BLOCK IS PLACED 
IN A WAIT QUEUE AND A RETURN TO THE DRIVER'S CALLER IS EXECUTED. THE 
ASSIGNMENT BLOCK WILL EVENTUALLY BE DEQUEUED WHEN THE UMR'S ARE 
AVAILABLE AND THE DRIVER WILL BE REMAPPED AND RETURNED TO WITH R1-R5 
PRESERVED AND THE NORMAL OUTPUTS OF THIS ROUTINE. THE DRIVER'S 
CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHILE IT IS 
BLOCKED AND IN THE WAIT QUEUE. ONCE A DRIVER'S MAPPING ASSIGNMENT 
BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS NOT REMOVED FROM THE 
QUEUE UNTIL THE UMR'S ARE SUCCESSFULLY ASSIGNED. THIS STRATEGY 
ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER'S 
WITH LARGE REQUESTS FOR UMR'S WILL NOT WAIT INDEFINITELY. 



INPUTS: 



R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB . 
(SP)=RETURN TO DRIVER'S CALLER. 

OUTPUTS: 

UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE 
ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB. 

NOTE: REGISTERS Rl, R2, AND R3 ARE PRESERVED ACROSS CALL. 



NOTE 

This routine pushes the address of 

routine $DQUMR+2 onto the stack before 

returning to the caller. A driver, 
therefore, should not use the stack for 

temporary data storage when calling this 
routine. 
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$STMP1 



SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 

This routine is in file MEMAP. It is used only for NPR devices that 
require UNIBUS Mapping Registers, support parallel operations, and 
have enabled 22-bit memory addressing. See Appendix B for a 
discussion of using this routine. 

Calling sequence: 

CALL $STMP1 

Description: 



**-$STMPl-SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 

THIS ENTRY CODE SETS UP AN ALTERNATE DATA STRUCTURE USED AS 
A UMR MAPPING ASSIGNMENT BLOCK AND CONTEXT STORAGE BLOCK, IN 
THE SAME MANNER AS $STMAP USES THE FORK BLOCK AND MAPPING 
BLOCK IN THE SCB. THE FORMAT OF THE STRUCTURE IS AS FOLLOWS: 



4 WORDS USED FOR SAVING 
DRIVER'S CONTEXT IN CASE 
UMR'S CAN'T BE MAPPED 
IMMEDIATELY. 



6 WORDS USED AS A UMR 
MAPPING ASSIGNMENT BLOCK. 



INPUTS: 

RO=ADDRESS OF THE DATA STRUCTURE DEPICTED ABOVE 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 

OUTPUTS: 

DATA STRUCTURE POINTERS SET UP FOR ENTRY TO $STMP2 IN $STMAP 



NOTE 

This routine pushes the address of 

routine $DQUMR+2 onto the stack before 

returning to the caller. A driver, 
therefore, should not use the stack for 

temporary data storage when calling this 
routine . 
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$SWSTK 



SWITCH STACKS 

This routine is in the file SYSXT. 

Calling sequence: 

SWSTK$ label 

The special macro in RSXMC.MAC must be used. 

Description: 

+ 
**$SWSTK-SWITCH STACKS 

THIS ROUTINE IS CALLED FROM TASK LEVEL TO SWITCH TO THE SYSTEM 
STACK THUS INHIBITING TASK SWITCHING. THE CALLING TASK MUST BE 
PRIVILEGED IF RUNNING IN A MAPPED SYSTEM AND MAPPED TO THE EXEC. 
CONTROL IS PASSED HERE FROM DRDSP AFTER THE TRAP HAS OCCURRED AND 
$DIRSV HAS BEEN CALLED. 

CALLING SEQUENCE: 

EMT 376 ;TRAP TO $EMSST IN DRDSP 

.WORD ADDR /ADDRESS FOR RETURN TO USER STATE 

INPUTS AT THIS POINT: 

R3=ADDRESS OF PC WORD OF TRAP ON STACK + 2 

MAPPED SYSTEM: 

22(SP)=PS PUSHED BY TRAP 

20{SP)=PC PUSHED BY TRAP 

16{SP)=SAVED R5 

14(SP)=SAVED R4 

12(SP)=SAVED R3 

10(SP)=SAVED R2 

06(SP)=SAVED Rl 

04 (SP)=SAVED RO 

02(SP)=RETURN ADDRESS FOR SYSTEM EXIT 

00(SP)=104376 

UNMAPPED SYSTEM: 

10(SP)=SAVED R3 
06(SP)=SAVED R2 
04(SP)=SAVED Rl 
02(SP)=SAVED RO 
00(SP)=RETURN ADDRESS FOR SYSTEM EXIT 

OUTPUTS: 

THE USER IS CALLED BACK ON THE SYSTEM STACK WITH ALL REGISTERS 
PRESERVED. TO RETURN TO TASK LEVEL THE CALLER MERELY EXECUTES 
A RETURN. 



Note: Task registers are not modified, 
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CHAPTER 6 
INCLUDING A USER-WRITTEN DRIVER — TWO EXAMPLES 



The first example that follows illustrates the procedures required to 
add a resident driver and resident data base to an RSX-11M system so 
that they can run on a system without support for loadable drivers and 
without multiuser protection. The driver in the example supports the 
punch capability of the PC11 Paper Tape Reader/Punch. 

Section 6.3 gives a coding example from a resident driver that 
inhibits the automatic packet queuing in QIO processing in order to 
address-check and relocate a special user buffer. 

In addition to the examples shown in this chapter, you should review 
the source code for one or more standard DIGITAL-supplied drivers. 
Also, examine file SYSTB.MAC, which contains data structures created 
by SYSGEN. 



6.1 DEVICE DESCRIPTION 

The PC 11 Paper Tape Reader/Punch is capable of reading 8-hole, 
unoiled, perforated paper tape at 300 char/s, and punching tape at 50 
char/s. The system consists of a paper tape reader/punch and 
controller. A unit containing only a reader (PR11) is also available. 

In reading tape, a set of photodiodes translates the presence or 
absence of holes in the tape to logic levels representing ones and 
zeroes. In punching tape, a mechanism translates logic levels 
representing ones and zeroes to the presence or absence, respectively, 
of holes in the tape. Any information read or punched is 
parallel-transferred through the controller. When an address is 
placed on the UNIBUS, the controller decodes the address and 
determines if the reader or punch has been selected. If one of the 
four device register addresses has been selected, the controller 
determines whether an input or an output operation should be 
performed. An input operation from the reader is initiated when the 
processor transmits a command to the paper tape reader status 
register. An output operation is initiated when the processor 
transfers a byte to the paper tape punch buffer register. 

The controller enables the PDP-11 system to control the reading or 
punching of paper tape in a flexible manner. The reader can be 
operated independently of the punch; either device can be under 
direct program control or can operate without direct supervision 
(through the use of interrupts) so as to maintain continuous 
operation. 
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6.2 DATA BASE AND DRIVER SOURCE 

The simplicity of writing a conventional driver for RSX-11M is 
obscured by the volume of explanation required to cover the universal 
case. As you will see below, building a conventional driver is a 
straightforward and modest undertaking. 



6. 2. 1 The Data Base 

The resident data base source shown below is self-explanatory. Take 
special note of the legal function mask words, starting at line 45. 
The standard function codes listed in Table 4-1 were used in creating 
the mask. Thus, the punch driver accepts the following I/O functions: 

• Cancel I/O (CAN) 

• Write Logical Block (WLB) 

• Attach Device (ATT) 

• Detach Device (DET) 

• Access File For Read/Write (ACW) 

• Access File For Read/Write/Extend (ACE) 

• Deaccess File (DAC) 

• Write Virtual Block (WVB) 

The CAN function is mandatory. The WLB function is the only transfer 
function actually supported. 

The ATT and DET functions are control functions. The three ATT/DET 
functions are legal for FCS and RMS compatibility, but are set to be 
no-ops. The WVB function is legal but is converted to WLB by QIO 
directive processing. 

The bit mask for each function is as follows: 

Function Function Code (octal) Mask (octal) Bit Range (decimal) 

CAN 

WLB 1 

ATT 3 

DET 4 

ACW 16 

ACE 17 

DAC 20 

WVB 22 



The legal masks result from adding the 0-15 (decimal) bit-range words 
to form a mask and all the 16-31 (decimal) bit-range words to form the 
second mask. 

The control, no-op, and ACP masks are created in an analogous fashion, 
matching bit positions with legal function code meanings. 

The complete set of mask words appears on lines 45 through 52 in the 
data structure source. 



6-2 



000001 


0-15. 


000002 


0-15. 


000010 


0-15. 


000020 


0-15. 


040000 


0-15. 


100000 


0-15. 


000001 


16.-31 


000004 


16.-31 
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The function code selections for record-oriented devices are intended 
to match FCS and RMS requirements for file-structured devices. When 
PCS or RMS executes an Access For Write, it is simply marked as a 
no-op. This tends to minimize FCS and RMS device-dependent logic. 
Note also on line 84 that the controller number, which is encoded in 
the low_ byte of the interrupt vector PS word in RSX-11M, is set to 
zero. Finally, since the code represents a resident data base, note 
that lines 78 through 85 would be omitted for a loadable data base. 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 



.TITLE USRTB 
.IDENT /01/ 

COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 

THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 
OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC. 

THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
EQUIPMENT CORPORATION. 

DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 
OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC. 

VERSION 01 

T. J. PASCUSNIK 25-NOV-74 

CONTROL BLOCKS FOR PAPER TAPE PUNCH DRIVER 

MACRO LIBRARY CALLS 



•MCALL DCBDF$,HWDDF$ 

DCBDF$ 

HWDDF$ 



;DEFINE DEVICE CONTROL BLOCK OFFSETS^ 
; DEFINE HARDWARE REGISTERS 



PAPER TAPE PUNCH DEVICE DATA BASE 
PAPER TAPE PUNCH DEVICE CONTROL BLOCK 



$USRTB : 
PPDCB : 



•WORD 

.WORD .PP0 

.ASCII /PP/ 

.BYTE 0,0 



.WORD 
.WORD 
• WORD 
.WORD 



PPND-PPST 
$PPTBL 
140033 
30 



LINK TO NEXT DCB 

POINTER TO FIRST UCB 

DEVICE NAME 

LOWEST AND HIGHEST UNIT NUMBERS COVERED 

BY THIS DCB 
LENGTH OF EACH UCB IN BYTES 
POINTER TO DRIVER DISPATCH TABLE 
LEGAL FUNCTION MASK CODES 0-15. 
CONTROL FUNCTION MASK CODES 0-15. 



1. Appendix C lists all macros 
control block offsets. 



that exist in RSX-11M to generate 
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47 




.WORD 


140000 


48 




.WORD 





49 




.WORD 


5 


50 




.WORD 





51 




• WORD 


1 


52 




.WORD 


4 


53 ; 








54 ; 


PAPER 


TAPE PUNCH UNIT CC 


55 ; 








56 . 


PPO: : 






57 PPST=. 






58 




.WORD 


PPDCB 


59 




.WORD 


.-2 


60 




.BYTE 


UC.ATT,0 


61 








62 




.BYTE 


0,0 


63 




.WORD 


DV. REC 


64 








65 




.WORD 





66 








67 




.WORD 





68 








69 




.WORD 


64. 


70 








71 




.WORD 


PPSCB 


72 




.WORD 





73 




.BLKW 


1 


74 








75 




.BLKW 


1 


76 




.BLKW 


1 


77 PPND=. 






78 








79 


PAPER 


TAPE PUNCH INTERR 


80 








81 




.ASECT 




82 


,=74 






83 




.WORD 


$PPINT 


84 




• WORD 


PR7J0 


85 




.PSECT 




86 








87 


• PAPER 


TAPE PUNCH STATUS 


88 








89 


PPSCB: 


.WORD 





90 








91 




.WORD 


.-2 


92 




.BYTE 


PR4,74/4 


93 




.BYTE 


0,4 


94 




.BYTE 


0,0 


95 








96 




.WORD 


177554 


97 




.BLKW 


1 


98 




.BLKW 


4 


99 








100 




.END 




6.2. 


2 Driver Code 





NO-P'ED FUNCTION MASK CODES 0-15. 
ACP FUNCTION MASK CODES 0-15. 
LEGAL FUNCTION MASK CODES 16.-31. 
CONTROL FUNCTION MASK CODES 16.-31. 
NO-OP'ED FUNCTION MASK CODES 16.-31. 
ACP FUNCTION MASK CODES 16.-31. 



BACK POINTER TO DCB 

POINTER TO REDIRECT UNIT UCB 

CONTROL PROCESSING FLAG (PASS CONTROL 

ON ATTACH/DETACH), UNIT STATUS 
PHYSICAL UNIT NUMBER, UNIT STATUS EXTENSION 
FIRST DEVICE CHARACTERISTICS WORD 

(RECORD-ORIENTED DEVICE) 
SECOND DEVICE CHARACTERISTICS WORD 

(FOR INTERNAL USE BY DRIVER) 
THIRD DEVICE CHARACTERISTICS WORD 

(FOR INTERNAL USE BY DRIVER) 
FOURTH DEVICE CHARACTERISTICS WORD 

(DEFAULT BUFFER SIZE IN BYTES) 
POINTER TO SCB 

TCB ADDRESS OF ATTACHED TASK 
RELOCATION BIAS OF BUFFER OF CURRENT 

I/O REQUEST 
ADDRESS OF BUFFER OF CURRENT I/O REQUEST 
BYTE COUNT OF CURRENT I/O REQUEST 



; ADDRESS OF INTERRUPT ROUTINE 

; INTERRUPT AT PRIORITY 7 (CONTROLLERS ) 



CONTROLLER I/O QUEUE LISTHEAD 

(POINTER TO FIRST ENTRY) 

(POINTER TO LAST ENTRY) 
DEVICE PR I, INTERRUPT VECTOR ADDRESS/4 
CURRENT AND INITIAL TIMEOUT COUNTS 
CONTROLLER INDEX AND STATUS 

(0=IDLE, 1=BUSY) 
ADDRESS OF CONTROL STATUS REGISTER 
ADDRESS OF CURRENT I/O PACKET 
FORK BLOCK ALLOCATION 



The code shown below for the punch capability of the PC11 is typical 

for a conventional driver. In fact, many of the descriptive comments 

can be used as a template and easily tailored to a driver for another 
device. 
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The structure of the driver follows the standard RSX-llM form, being 
separated into processing code for the following: 

• Initiator 

• Power failure 

• Interrupt 

• Time-out 

• Cancel I/O 

The driver itself services only Write Logical, Attach, and Detach I/O 
functions. Attach and Detach result in the punching of 170. nulls 
each for header and trailer. 

Power failure and cancel I/O are handled by means of device time-out, 
as is the device-not-ready condition. 

The driver uses the following Executive services: 

$INTXT 
$GTPKT 
$GTBYT 
$DVMSG 



$INTSV is used indirectly; it is called by INTSV$ (line 165) 
Section 4.3. 



See 



Comments beginning with • ; ; ; • indicate that the instruction is being 
executed at a priority level greater than or equal to 4. 

The code contained in lines 139-141 is used to inhibit the punching of 
a trailer on ATT/DET if the task is being aborted. This is especially 
desirable when the device is not ready (for example, out of paper 
tape) and the system has generated the DET function for the aborting 
process. 



1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 
10. 
11. 
12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20. 
21. 
22. 
23. 
24. 



.TITLE PPDRV 
.IDENT /0 2/ 



COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 

THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 
OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC. 

THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
EQUIPMENT CORPORATION. 

DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 
OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC. 

VERSION 02 

T. J. PASCUSNIK 25-NOV-74 

MODIFIED BY: 
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25. 
26. 

27. 
28. 
29. 

30. 
31. 
32. 
33. 
34. 
35. 
36. 
37. 
38. 
39. 
40. 
41. 
42. 
43. 
44. 
45. 
46. 
47. 
48. 
49. 

50. 
51. 
52. 
53. 
54. 

55. 

56. 

57. 

58. 

59. 

60. 

61. 

62. 

63. 

64. 

65. 

66. 

67. 

68. 

69. 

70. 

71. 

72. 

73. 

74. 

75. 

76. 

77. 

78. 

79. 

80. 

81. 

82. 

83. 

84. 

85. 

86. 

87. 

88. 



C. A. ANDERS 15-MAR-76 

CA001 ~ ADDITION OF LOADABLE DRIVER SUPPORT. 
T. J. PASCUSNIK 4-APR-76 

TP031 — EXECUTIVE DATA STRUCTURE CHANGES. 

PC11 PAPER TAPE PUNCH DRIVER 
MACRO LIBRARY CALLS 

.MCALL ABODF$,HWDDF$,PKTDF$,TCBDF$ 



ABODF$ 
HWDDF$ 
PKTDF$ 
TCBDF$ 



DEFINE TASK ABORT CODES 

DEFINE HARDWARE REGISTER SYMBOLS 

DEFINE I/O PACKET OFFSETS 

DEFINE TASK CONTROL BLOCK OFFSETS 



EQUATED SYMBOLS 

PAPER TAPE PUNCH STATUS WORD BIT DEFINITIONS (U.CW2) 



WAIT=100000 
ABORT=40000 
TRAIL=200 



WAITING FOR DEVICE TO COME ON-LINE (1=YES) 
ABORT CURRENT I/O REQUEST (1=YES) 
CURRENTLY PUNCHING TRAILER (1=YES) 



LOCAL DATA 

CONTROLLER IMPURE DATA TABLES (INDEXED BY CONTROLLER NUMBER) 



CNTBL: .BLKW P$$P11 

.IF GT P$$P11-1 
TEMP: .BLKW 1 
.ENDC 

DRIVER DISPATCH TABLE 



$PPTBL:: .WORD PPINI 

.WORD PPCAN 

.WORD PPOUT 

.WORD PPPWF 



;ADDRESS OF UNIT CONTROL BLOCK 



;TEMPORARY STORAGE FOR CONTROLLER NUMBER 

; CAOO] 
; CA001 



DEVICE INITIATOR ENTRY POINT 
CANCEL I/O OPERATION ENTRY POINT 
DEVICE TIMEOUT ENTRY POINT 
POWERFAIL ENTRY POINT 



**-PPINI-PCll PAPER TAPE PUNCH CONTROLLER INITIATOR 

THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 
IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECU- 
TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT 
IS MADE TO DEQUEUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS 
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPER- 
ATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED. 
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89. 
90. 
91. 
92. 
93. 
94. 
95. 
96. 
97. 
98. 
99. 

100. 

101. 

102. 

103. 

104. 

105. 

106. 

107. 

108. 

109. 

110. 

111. 

112. 

113. 

114. 

115. 

116. 

117. 

118. 

119. 

120. 

121. 

122. 

123. 

124. 

125. 

126. 
127. 
128. 
129. 
130. 
131. 
132. 
133. 
134. 
135. 
136. 
137. 
138. 
139. 
140. 
141. 
142. 
143. 
144. 
145. 
146. 
147. 
148. 
149. 
150. 
151. 



INPUTS: 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 

OUTPUTS: 

IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT- 
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER- 
ATION IS INITIATED. 



.ENABL LSB 
PPINI: CALL SGTPKT 

BCS PPPWF 



;GET AN I/O PACKET TO PROCESS 

;IF CS CONTROLLER BUSY OR NO REQUEST 



THE FOLLOWING ARGUMENTS ARE RETURNED BY $GTPKT: 



R1=ADDRESS OF THE I/O REQUEST PACKET. 

R2=PHYSICAL UNIT NUMBER OF THE REQUEST UCB. 

R3=CONTROLLER INDEX. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 



PAPER TAPE PUNCH I/O REQUEST PACKET FORMAT: 



10$: 
20$: 



WD. 00 

WD. 01 

WD. 02 

WD. 03 

WD. 04 

WD. 05 



- I/O QUEUE THREAD WORD. 

- REQUEST PRIORITY, EVENT FLAG NUMBER. 

- ADDRESS OF THE TCB OF THE REQUESTER TASK. 

- POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER. 

- CONTENTS OF THE FIRST LUN WORD IN REQUESTER TASK HEADER (UCB) 

- I/O FUNCTION CODE (IO.WLB, 10. ATT OR IO.DET). 

- VIRTUAL ADDRESS OF I/O STATUS BLOCK. 

- RELOCATION BIAS OF I/O STATUS BLOCK. 

- I/O STATUS BLOCK ADDRESS (REAL OR DISPLACEMENT + 140000) 

- VIRTUAL ADDRESS OF AST SERVICE ROUTINE. 
WD. 12 -- - RELOCATION BIAS OF I/O BUFFER. 

WD. 13 — BUFFER ADDRESS OF I/O TRANSFER. 
WD. 14 — NUMBER OF BYTES TO BE TRANSFERED. 
WD. 15 — NOT USED. 
WD. 16 — NOT USED. 
WD. 17 — NOT USED. 
WD. 20 — NOT USED. 



WD. 
WD. 
WD. 
WD. 



06 
07 
10 
11 



MOV R5,CNTBL(R3) 

CLR U.CW2(R5) 

CMPB I.FCN+1(R1),#I0 

BEQ 10$ 

MOV I.TCB(R1),R0 

BIT #T2.ABO,T.ST2(R 

BNE 65$ 

BIS #TRAIL,U.CW2(R5 



MOV #170.,U.CNT(R5) 

BIS #WAIT,U.CW2(R5) 

TST @S.CSR(R4) 

BMI 80$ 

BIC #WAIT,U.CW2(R5) 

MOVB S. ITM (R4) ,S.CTM 

MOV #100,@S.CSR(R4) 



;SAVE UCB POINTER FOR INTERRUPT ROUTINE 

; CLEAR ALL SWITCHES 

WLB/256. ;WRITE LOGICAL BLOCK FUNCTION? 

;IF EQ YES 

;GET REQUESTOR TCB ADDRESS 
0) ;TASK BEING ABORTED? ; TP031 

;IF NE YES - DON'T PUNCH TRAILER 
) ;OTHERWISE FUNCTION IS ATTACH OR DETACH 
SET FLAG TO PUNCH TRAILER 

;SET COUNT FOR 170 NULLS 

.•ASSUME WAIT FOR DEVICE OFF LINE 

; DEVICE OFF LINE? 

;IF MI YES 

; DEVICE ON LINE, CLEAR WAIT CONDITION 
(R4) ;SET TIMEOUT COUNT 

; ENABLE INTERRUPTS 
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152. 

153. 

154. 

155. 

156. 

157. 

158. 

159. 

160. 

161. 

162. 

163. 

164. 

165. 

166. 

167. 

168. 

169. 

170. 

171. 

172. 

173. 

174. 

175. 

176. 

177. 

178. 

179. 

180. 

181. 

182. 

183. 

184. 

185. 

186. 

187. 

188. 

189. 

190. 

191. 

192. 

193. 

194. 

195. 

196. 

197. 

198. 

199. 

200. 

201. 

202. 

203. 

204. 

205. 

206. 

207. 

208. 

209. 

210. 

211. 

212. 

213. 

214. 

215. 



POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND THEREFORE CAUSES 
NO IMMEDIATE ACTION ON THE DEVICE. THIS IS DONE TO AVOID A RACE CONDITION 
THAT COULD EXIST IN RESTARTING THE I/O OPERATION 



PPPWF: RETURN 



**-$PPINT-PCll PAPER TAPE PUNCH CONTROLLER INTERUPTS 



$PPINT: : 



30$: 

40$: 
50$: 
60$: 



65$: 
70$: 



INTSV$ PP,PR4,P$$P11 

MOV U.SCB(R5),R4 

MOVB S.ITM(R4),S.CTM 

MOV S.CSR(R4),R4 

MOV (R4)+,U.CW3(R5) 

BMI 60$ 

SUB #1,U.CNT(R5) 

BCS 50$ 

TSTB U.CW2(R5) 

BPL 30$ 

CLRB (R4) 

BR 40$ 

CALL $GTBYT 

MOVB (SP)+,(R4) 

■JMP $INTXT 

INC U.CNT(R5) 

CLR -(R4) 

CALL $FORK 

MOV U.SCB(R5),R4 

MOV S.PKT(R4),R1 

MOV I.PRM+4 (Rl) ,R1 

SUB U.CNT(R5),R1 

MOV #IS.SUC&377,R0 

TST U.CW3(R5) 

BPL 70$ 

MOV #IE.VER&377,R0 

CALL $IODON 

BR PPINI 



REF LABEL 

GENERATE INTERRUPT SAVE CODE ; CA001 

GET ADDRESS OF STATUS CONTROL BLOCK 
(R4) ;;, -RESET TIMEOUT COUNT 

POINT R4 TO CONTROL STATUS REGISTER 

SAVE STATUS 

IF MI, ERROR 

DECREMENT CHARACTER COUNT 

IF CS, THEN DONE 

CURRENTLY PUNCHING TRAILER? 

IF PL NO 

LOAD NULL INTO OUTPUT REGISTER 

BRANCH TO LOAD IT 

GET NEXT BYTE FROM USER BUFFER 

LOAD BYTE INTO OUTPUT REGISTER 

EXIT FROM INTERRUPT 

RESET BYTE COUNT 

DISABLE PUNCH INTERRUPTS 

CREATE SYSTEM PROCESS 
; POINT R4 TO SCB 
? POINT Rl TO I/O PACKET 
; AND PICK UP CHARACTER COUNT 
.-CALCULATE CHARACTERS TRANSFERRED 
;ASSUME SUCCESSFUL TRANSFER 
; DEVICE ERROR? 
;IF PL NO 

; UNRECOVERABLE HARDWARE ERROR CODE 
; INITIATE I/O COMPLETION 
;BRANCH BACK FOR NEXT REQUEST 



DEVICE TIMEOUT RESULTS IN A NOT READY MESSAGE BEING PUT OUT 4 TIMES A 
MINUTE. TIMEOUTS ARE CAUSED BY POWERFAILURE AND PUNCH FAULT CONDITIONS. 



PPOUT: CLRB @S.CSR(R4) 

CLRB PS 

80$: MOV #IE.DNR&377,R0 

MOV U.CW2(R5),R1 

BPL 70$ 

MOV #IE.ABO&377,R0 

ASL Rl 

BMI 70$ 

TST @S.CSR(R4) 

BPL 20$ 

MOV #T.NDNR,R0 

MOVB #1,S.CTM(R4) 

DECB S.STS(R4) 

BNE PPPWF 

MOVB #15.,S.STS(R4) 

CALLR $DVMSG 

.DSABL LSB 



;S 



;, -DISABLE PUNCH INTERRUPT 

;;ALLOW INTERRUPTS 

ASSUME DEVICE NOT READY ERROR 

ARE WE WAITING FOR DEVICE READY? 

IF PL NO, TERMINATE I/O REQUEST 

ASSUME REQUEST IS TO BE ABORTED 
: ABORT REQUEST? 

IF MI YES 

PUNCH READY? 
:IF PL YES 

SET FOR NOT READY MESSAGE 
:SET TIMEOUT FOR 1 SECOND 
;TIME TO OUTPUT MESSAGE? 
:IF NE NO 

ET TO OUTPUT NEXT MESSAGE IN 15. SECONDS 

OUTPUT MESSAGE AND RETURN 
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INCLUDING A USER-WRITTEN DRIVER— TWO EXAMPLES 



216. 
217. 
218. 
219. 
220. 
221. 
222. 
223. 
224. 
225. 
226. 



CANCEL I/O OPERATION-FORCE I/O TO COMPLETE IF DEVICE IS NOT READY 



PPCAN: 



10$: 



CMP 
BNE 
BIS 
RETURN 

.END 



R1,I.TCB(R0) 

10$ 

#ABORT,U.CW2(R5) 



REQUEST FOR CURRENT TASK? 

IF NE NO 

;SET FOR ABORT IF DEVICE NOT READY 



6.3 HANDLING SPECIAL USER BUFFERS 

Some drivers need to handle user buffers in addition to the buffer 
that the Executive address-checks and relocates in a normal transfer 
request. Address checking and relocation operations must take place 
in the context of the task issuing the I/O request, because the 
mapping registers are set for the issuing task. However, in the 
normal driver interface, the task context after the call to $GTPKT is 
not, in general, that of the issuing task. 

Thus, drivers that need to handle special buffers must be able to 
reference the I/O packet before it is queued, while the context of the 
issuing task is still intact. 

The following coding excerpts from a standard RSX-llM driver (the 
AFC11 driver) illustrate the handling of a special user buffer. The 
key points are: 

• The UC.QUE bit has been set in the control byte (U.CTL) of the 
UCB for each device/unit. (This is not shown in the codinq 
excerpts below.) 

• The routine that is referenced as the initiator entry point in 
the driver dispatch table performs the following actions: 

1. Picks up the user virtual address and conditionally 
address-checks it. 

2. Relocates the virtual address, storing the result back 
into the packet. 

3. Inserts the packet into the I/O queue and falls through 
to the entry point AFINI, which calls $GTPKT. 

• The driver propagates its own execution by branchinq back to 
AFINI to call $GTPKT. 



DRIVER DISPATCH TABLE 



$AFTBL: :.W0RD AFCHK 

.WORD AFCAN 

.WORD AFOUT 

.WORD AFPWF 



DEVICE INITIATOR ENTRY POINT 
CANCEL I/O OPERATION ENTRY POINT 
DEVICE TIMEOUT ENTRY POINT 
POWERFAIL ENTRY POINT 
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INCLUDING A USER-WRITTEN DRIVER — TWO EXAMPLES 



**-AFCHK-AFCll ANALOG TO DIGITAL CONVERTER CONTROLLER PARAMETER CHECKING 

THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 
IS RECEIVED FOR THE AFC11 ANALOG TO DIGITAL CONVERTOR. AFC11 I/O REQUESTS 
CONTAIN DEVICE DEPENDENT INFORMATION THAT MUST BE CHECKED IN THE CONTEXT 
OF THE ISSUING TASK. THEREFORE THE I/O REQUEST IS NOT QUEUED BEFORE CALLING 
THE DRIVER. 



INPUTS: 



R1=ADDRESS OF THE I/O REQUEST PACKET. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 

R5=ADDRESS OF THE UCB OF THE CONTROLER TO BE INITIATED. 



OUTPUTS: 



THE CONTROL BUFFER IS ADDRESS CHECKED TO DETERMINE WHETHER IT LIES 
WITHIN THE ISSUING TASK'S ADDRESS SPACE. IF THE ADDRESS CHECK 
SUCCEEDS THEN THE CONTROL BUFFER ADDRESS IS RELOCATED AND STORED 
IN THE I/O PACKET, THE I/O PACKET IS INSERTED IN THE CONTROLLER 
QUEUE. AND THE DEVICE INITIATOR IS ENTERED TO START THE CONTROLLER. 
ELSE AN ILLEGAL BUFFER STATUS IS RETURNED AS THE FINAL I/O STATUS 
OF THE REQUEST. 



;COPY ADDRESS OF I/O PACKET 

;GET VIRTUAL ADDRESS OF CONTROL BUFFER 



SET LENGTH OF BUFFER TO CHECK 
ADDRESS CHECK CONTROL BUFFER 
IF CC ADDRESS OKAY 
SET ILLEGAL BUFFER STATUS 
FINISH I/O OPERATION 



RELOCATE CONTROL BUFFER ADDRESS 

SET RELOCATION BIAS OF CONTROL BUFFER 

SET ADDRESS OF CONTROL BUFFER 

SET ADDRESS OF I/O PACKET 

SET ADDRESS OF I/O QUEUE LISTHEAD 

INSERT I/O PACKET IN REQUEST QUEUE 



AFCHK: 


MOV 


R1,R3 ?< 




MOV 


I.PRM+6(R3),R0 ;( 




.IF DF 


A$$CHK!M$$MGE 




MOV 


I.PRM+4(R3),R1 ; 




CALL 


$ACHCK 




BCC 


10$ 




MOV 


#IE.SPC&377,R0 ; 




CALLR 


$IOFIN 




.ENDC 




10$: 


CALL 


$RELOC ; 




MOV 


R1,I.PRM+6(R3) ; 




MOV 


R2,I.PRM+10(R3) ; 




MOV 


R3,R1 




MOV 


R4,R0 r 




CALL 


$QINSP 
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**-AFINI-AFCll ANALOG TO DIGITAL CONVERTOR CONTROLLER INITIATOR 

THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 
IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECU- 
TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT 
IS MADE TO DEQUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS 
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPER- 
ATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED. 

INPUTS: 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 

OUTPUTS: 

IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT 
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER- 
ATION IS INITIATED. 



.ENABL LSB 
AFINI: CALL $GTPKT 

BCS AFCAN 



;GET AN I/O PACKET TO PROCESS 

;IF CS CONTROLLER BUSY OR NO REQUEST 

;I/0 CANCEL (AFCAN) IS A NO-OP FOR AFC11 



CALL 
BR 



$IODON 
AFINI 



;FINISH I/O OPERATION 
;GO AGAIN 
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APPENDIX A 
DEVELOPMENT OF THE ADDRESS DOOBLEWORD 



A.l INTRODUCTION 

You can generate an RSX-11M system as a mapped or an unmapped system. 
Mapped systems can accommodate configurations whose maximum physical 
memory is 4096K bytes. Individual tasks, however, are limited to 64K 
bytes. The addressing in a mapped system uses virtual addresses and 
memory mapping hardware. I/O transfers, however, use physical 
addresses 18 bits in length. Since the PDP-11 word size is 16 bits, 
some scheme is necessary to represent an address internally until it 
is actually used in an I/O operation. The choice was made to encode 
two words as the internal representation of a physical address, and to 
transform virtual addresses for I/O operations into the internal 
doubleword format. 



A. 2 CREATING THE ADDRESS DOUBLEWORD 

For unmapped systems, the doubleword is simply a word of zeros 
followed by a word containing the real address. 

On receipt of a QIO directive for mapped systems, the buffer address 
in the DPB, which contains a task virtual address, is converted to 
address doubleword format. 

The virtual address in the DPB is structured as follows: 

Bits 0-5 Displacement in terms of 32-word blocks 

Bits 6-12. Block number 

Bits 13.-15. Page Address Register (PAR) number 
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DEVELOPMENT OF THE ADDRESS DOUBLEWORD 

The internal RSX-11M translation restructures this virtual address 
into an address doubleword as follows: 

1. The relocation base contained in the PAR specified by the PAR 
number in the virtual address in the DPB is added to the 
block number in the virtual address. The result becomes the 
first word of the address doubleword. It represents the nth 
32-word block in a memory viewed as a collection of 32-word 
blocks. Note that at the time the address doubleword is 
computed, the user issuing the QIO directive is mapped into 
the processor's memory management registers. 

2. The second word is formed by placing the 
displacement-in-block (bits 0-5 of virtual address) into bits 
0-5. The block number field was accommodated in the first 
word and bits 6-12. are cleared. Finally, a 6 is placed in 
bits 13.-15. to enable use of PAR #6, which the Executive 
uses to service I/O for program transfer devices. 

For non-processor request (NPR) devices, the driver 
requirements for manipulating the address doubleword are 
direct and are discussed with the description of U.BUF in 
Section 4.1.4.1. 



A-2 



APPENDIX B 
DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY 



You must build special features into drivers for nonextended memory 
NPR devices attached to a PDP-11 processor with extended-memory 
support (22-bit addressing). 

Nonextended memory NPR devices on the PDP-11 processor must perform 
I/O transfers by means of UNIBUS Mapping Registers (UMRs) , as 
described in the PDP-11 Processor Handbook . One UMR is required for 
each 4K words involved in the transfer — as specified by the contents 
of U.CNT in the UCB. When multiple UMRs are required for a transfer, 
they must be contiguous. 

A driver can be assigned UMRs through one of three procedures. These 
procedures involve the following: 

1. Dynamically allocating UMRs for the duration of the data 
transfer 

2. Dynamically allocating UMRs for longer periods of time 

3. Statically allocating UMRs during system generation 

NOTE 

In large systems, using the second and 
third procedures above to hold UMRs for 
longer periods than necessary can result 
in the blocking of other drivers and a 
reduction in system throughput. 



B.l CALLING $STMAP AND $MPUBM OR $STMP1 AND $MPUB1 

To obtain UMRs through use of the $STMAP and $MPUBM or $STMP1 and 
$MPUB1 routines, a driver must: 

1. If it uses $STMAP and $MPUBM or $STMP1 and $MPUB1, allocate 
six additional words for a mapping register assignment block 
at the end of the device's SCB (at S.MPR) . If it uses $STMP1 
and $MPUB1, also provide a 10-word block. 

2. Call the routine $STMAP or $STMP1 (set up UNIBUS mapping 
address) after getting the I/O packet. 

3. Call the routine $MPUBM or $MPUB1 (map UNIBUS to memory) 
before initiating a transfer. 
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These requirements are detailed in the following three subsections. 

Note that these routines are only required when the driver is 
performing a data transfer. 



B.l.l Allocating a Mapping Register Assignment Block 

The status control block (SCB) of an NPR device requires an additional 
six words. This 6-word mapping register assignment block is located 
at S.MPR, at the end of the SCB. It does not have to be initialized. 
Any initial contents are simply overwritten. 

The following example shows the allocation of a mapping register 
assignment block. The code is conditional on the result of an AND 
operation on the two symbols M$$EXT and M$$MGE (representing extended 
memory support and memory management unit support, respectively). 

.IF DF M$$EXT&M$$MGE 

•BLKW 6 ;UMR WORK AREA 

• ENDC 



- opei ___„..... --.-,----..-, -. „,.. r -.. 3 , - ,-. - , 

In the latter situation, the six additional words starting at S.MPR in 
the SCB are not used but must still be present. In addition, the 
driver must provide a 10-word mapping register assignment block for 
each data transfer to be mapped, as specified in the description of 
$STMP1 in Chapter 5. 



B.1.2 Calling $STMAP or $STMP1 

In the coding at the initiator entry point, after the call to $GTPKT, 
the NPR device driver must call the routine $STMAP or $STMP1. These 

routines dynamically allocate required UMRs . If UMRs are not 

available immediately, the driver is blocked. Such blocking, if it 

occurs, is completely transparent to the driver. The driver resumes 

processing at fork level when the UMRs have been allocated. The 

register returns are absolutely identical whether or not blocking has 
occurred. 

SSTMAP or $STMP1 stores into U.BUF and U.BUF+2 (in the UCB) a UNIBUS 
address that causes the appropriate UMR to be selected for mapping the 
transfer. The call to $STMAP or $STMP1 must be conditional on M$$EXT 
and M$$MGE. 

Because $STMAP and $STMP1 push the address of routine $DQUMR+2 onto 
the stack before returning to the caller, the driver should not use 
the stack for temporary data storage when it calls $STMAP or $STMP1. 
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B.1.3 Calling $MPUBM or $MPUB1 

Before executing the transfer, the driver must call $MPUBM or $MPUB1. 
These routines get the buffer's 22-bit physical address, and load the 
UNIBUS mapping registers so that transfers are mapped directly to the 
task's space. The call to $MPUBM or $MPUB1 must be conditional on 
M$$EXT and M$$MGE. 

If the driver calls $STMAP and $MPUBM, the UMRs allocated to it are 
deallocated during the call to $IODON or $IOALT. If the driver calls 
$STMP1 and $MPUB1, it must call $DEUMR to deallocate any allocated 
UMRs before calling $IODON or $IOALT. 



B.2 CALLING $ASUMR AND $DEUMR 

Some drivers may not require UMRs to be allocated all of the time, and 
yet require UMRs for periods of time longer than the normal time frame 
between $GTPKT and $IODON (or $IOALT) . In such cases, there is a 
second procedure for allocating UMRs. 

By using the Executive routines $ASUMR and $DEUMR, a driver can 
dynamically allocate, retain over a desired time frame, and deallocate 
UMRs. Refer to Section 5.3 for a description of the $ASUMR and $DEUMR 
routines. 

Similar to the $STMAP/$MPUBM procedure, using $ASUMR and $DEUMR also 
requires the allocation of a 6-word mapping register assignment block. 
In this instance, however, the block must not be located at offset 
S.MPR in the SCB. $IODON or $IOALT, when called, will attempt to 
deallocate the UMRs of a block found at location S.MPR. To avoid 
this, the mapping register assignment block could, for convenience, be 
located at S.MPR+2. Alternatively, it could be dynamically allocated 
from the pool. Figure B-l details the format of the 6-word block. 



M.LNK 


Link Word 


M.UMRA 


Address of first assigned UMR 


M.UMRN 


Number of assigned UMRs *4 


M.UMVL 


Low 16 bits mapped by first assigned UMR 


M.UMVH 
M.BFVH 


High 6 bits of 
physical buffer address 


High 2 bits mapped by 
UMR (in bits 4 and 5) 


M.BFVL 


Low 1 6 bits of physical buffer address 



Figure B-l Mapping Register Assignment Block 
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B.3 STATICALLY ALLOCATING UMRS DURING SYSTEM GENERATION 

You can statically assign UMRs during system generation. For systems 
with extended memory support and memory management unit support, the 
system generation procedure defines the symbol N$$UMR equal to a fixed 
number of UMRs, multiplied by 4, that are statically assigned to the 
system. Before assembling the Executive, you can cause the static 
allocation of an additional number of UMRs by editing file RSXMC.MAC. 
The value of the symbol N$$UMR can then be increased to represent the 
additional number of desired UMRs multiplied by 4. 

RSXMC.MAC further defines the following three symbols, which describe 
the first UMR statically allocated during system generation: 

U$$MRN is the I/O page address of the first UMR register 
available for allocation to the user. 

U$$MLO represents the low-order 16 bits of the 18-bit UNIBUS 
address mapped by this UMR. 

U$$MHI represents the high-order two bits of the 18-bit UNIBUS 
address. These two bits are in bit positions 4 and 5. 

These three symbols are not used by the system itself. They are 
available for the user's information. 
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APPENDIX C 
SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 



This appendix describes the system data structures listed in Table 
C-l. 

The data structures are defined by macros in the Executive macro 

library. To reference any of the data structure offsets from your 

code, include the macro name in an .MCALL directive and invoke the 
macro. For example: 

.MCALL DCBDF$ 

DCBDF$ ;Define DCB offsets 

NOTE 

All physical offsets and bit definitions 
are subject to change in future releases 
of the operating system. Code that 
accesses system data structures should 
always use the symbolic offsets rather 
than the physical offsets. 

The first two arguments, <:> and <=>, make all definitions global. If 
they are left blank, the definitions will be local. The^SYSDEF 
argument causes the variable part of a data structure to be defined. 

All of these macros are in the Executive macro library 
LB: [1,1]EXEMC.MLB. All except ITBDF$ and MTADF$ are also in the 
Executive definition library LB: [1, 1]EXELIB.0LB. 
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Table C-l 
Summary of System Data Structure Macros 



Macro 



Arguments 



ABODF$ <:>,<=> 

CLKDF$ <:>,<=> 

DCBDF$ <:>,<=> 

EPKDF$ <:>,<=> 

F11DF$ <:>,<=>, SYSDEF 

HDRDF$ <:>,<=> 

HWDDF$ <:>,<=> 

ITBDF$ <:>,<=>, SYSDEF 

LCBDF$ <:>,<=> 

MTADF$ <:>,<=> 

PCBDF$ <:>,<=>, SYSDEF 

PKTDF$ <:>,<=> 

SCBDF$ <:>,<=>, SYSDEF 

UCBDF$ <:>,<=>,TTDEF, SYSDEF 



Data Structures 



Task abort and termination 
notification message codes 

Clock queue control block 

Device Control Block 

Error message block 

Files-11 data structures (volume 
control block, mount list entry, 
file control block, file window 
block, locked block list node) 

Task header and window block 

Hardware register addresses and 
feature mask definitions 

Interrupt transfer block 

Logical assignment control block 

ANSI magtape data structures 
(volume set control block) 

Partition control block and 
attachment descriptor 

I/O packet, AST control block, 

offspring control block, group 

global event flag control block, 
and CLI parser block 

Task Control Block 

Unit Control Block 
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ABODF$ 



ABODF$ 



TASK ABORT CODES 

NOTE: S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS 



S.CACT=-4. 

S.CEXT=-2. 

S.COAD=0. 

S.CSGF=2. 

S.CBPT=4. 

S.CIOT=6. 

S.CILI=8. 

S.CEMT=10. 

S.CTRP=12. 

S.CFLT=14. 

S.CSST=16. 

S.CAST=18. 

S.CABO=20. 

S.CLRF=22. 

S.CCRF=24. 

S.IOMG=26. 

S.PRTY=28. 

S.CPMD=3 0. 

S.CINS=32. 



TASK STILL ACTIVE 

TASK EXITTED NORMALLY 

ODD ADDRESS AND TRAPS TO 4 

BREAK POINT OR TRACE TRAP 

IOT INSTRUCTION 

ILLEGAL OR RESERVED INSTRUCTION 

NON RSX EMT INSTRUCTION 

TRAP INSTRUCTION 

11/40 FLOATING POINT EXCEPTION 

SST ABORT-BAD STACK 

AST ABORT-BAD STACK 

ABORT VIA DIRECTIVE 

TASK LOAD REQUEST FAILURE 

TASK CHECKPOINT READ FAILURE 

TASK EXIT WITH OUTSTANDING I/O 

TASK MEMORY PARITY ERROR 

TASK ABORTED WITH PMD REQUEST 

TASK INSTALLED IN TWO SYSTEMS 



| TASK TERMINATION NOTIFICATION MESSAGE CODES 



T.NDNR=0 

T.NDSE=2 

T.NCWF=4 

T.NCRE=6 

T.NDMO=8. 

T.NUER=10. 

T.NLDN=12. 

T.NLUP=14. 

T.NCFI=16. 

T.NUDE=18. 

T.NMPE=20. 

T.NKLF=22. 

T.NDEB=24. 

T.NRCT=26. 

T.NWBL=28. 



DEVICE NOT READY 

DEVICE SELECT ERROR 

CHECKPOINT WRITE FAILURE 

CARD READER HARDWARE ERROR 

DISMOUNT COMPLETE 

UNRECOVERABLE ERROR 

LINK DOWN (NETWORKS) 

LINK UP (NETWORKS) 

CHECKPOINT FILE INACTIVE 

UNRECOVERABLE DEVICE ERROR 

MEMORY PARITY ERROR 

UCODE LOADER NOT INSTALLED 

TASK HAS NO DEBUGGING AID 

REPLACEMENT CONTROL TASK NOT INSTALLED 

WRITE BACK CACHING DATA LOST 

UNIT WRITE LOCKED 
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CLKDF$ 



CLKDF$ 



CLOCK QUEUE CONTROL BLOCK OFFSET DEFINITIONS 

CLOCK QUEUE CONTROL BLOCK 

THERE ARE SIX TYPES OF CLOCK QUEUE CONTROL BLOCKS. EACH CONTROL 

;he C rem H mnSg ?h^e E e! 0RMAT IN ™ E FIRST FIVE wo^s-and C Siff°ers°in 

THE FOLLOWING CONTROL BLOCK TYPES ARE DEFINED: 



C.MRKT=0 

C.SCHD=2 

C.SSHT=4 

C.SYST=6 

C.SYTK=8. 

C.CSTP=10. 



MARK TIME REQUEST 

TASK REQUEST WITH PERIODIC RESCHEDULING 

SINGLE SHOT TASK REQUEST 

SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (IDENT) 

SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (TASK) 

CLEAR STOP BIT (CONDITIONALIZED ON SHUFFLING 



000000 
000002 
000003 
000004 
000006 



CLOCK QUEUE CONTROL BLOCK TYPE INDEPENDENT OFFSET DEFINITIONS 



.=0 

C.LNK: 

C . RQT : 

C.EFN: 

C.TCB: 

C.TIM: 



•ASECT 

• BLKW 
.BLKB 
.BLKB 
.BLKW 

• BLKW 



1 
1 
1 
1 
2 



; CLOCK QUEUE THREAD WORD 

; REQUEST TYPE 

; EVENT FLAG NUMBER (MARK TIME ONLY) 

;TCB ADDR OR SYSTEM SUBROUTINE IDENTIFICATION 

;ABSOLUTE TIME WHEN REQUEST COMES DUE 



CLOCK QUEUE CONTROL BLOCK-MARK TIME DEPENDENT OFFSET DEFINITIONS 



•=C.TIM+4 



000012 CAST 
000014 C.SRC 
000016 C.DST 



.BLKW 
.BLKW 
• BLKW 



START OF DEPENDENT AREA 

AST ADDRESS 

FLAG MASK WORD FOR 'BIS' SOURCE 

ADDRESS OF 'BIS' DESTINATION 



n^rS™ C0NTR0L BLOCK-PERIODIC RESCHEDULING DEPENDENT OFFSET 
Uhr IN IT IONS 



.=C.TIM+4 
000012 C.RSI: .BLKW 2 
000016 C.UIC: .BLKW 1 



; START OF DEPENDENT AREA 
.-RESCHEDULE INTERVAL IN CLOCK TICKS 
/SCHEDULING UIC 



CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT DEPENDENT OFFSET DEFINITIONS 



.=C.TIM+4 
000012 .BLKW 2 

000016 .BLKW 1 



START OF DEPENDENT AREA 
TWO UNUSED WORDS 
SCHEDULING UIC 
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CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET 
DEFINITIONS 

THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST: 

TYPE 6 = SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE 
AS AN IDENTIFIER. 

TYPE 8 = SINGLE SHOT INTERNAL SUBROUTINE WITH A TCB ADDRESS 
AS AN IDENTIFIER. 



.=C.TIM+4 

000012 C.SUB: .BLKW 1 

000014 C.AR5: .BLKW 1 

000016 .BLKW 1 



; START OF DEPENDENT AREA 

; SUBROUTINE ADDRESS 

/RELOCATION BASE (FOR LOADABLE DRIVERS) 

;ONE UNUSED WORD 



000020 C.LGTH=. 



;LENGTH OF CLOCK QUEUE CONTROL BLOCK 



PSECT 
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DCBDF$ 



DCBDF$ 



DEVICE CONTROL BLOCK 

THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT 
A DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS. THERE IS 
AT LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM. FOR EXAMPLE, 
IF THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE 
DCB WITH THE DEVICE NAME "TT". IF PART OF THE TELETYPES WERE 
INTERFACED VIA DLll-A'S AND THE REST VIA A DH11, THEN THERE 
WOULD BE TWO DCB'S. ONE FOR ALL DL11-A INTERFACED TELETYPES, 
AND ONE FOR ALL DH11 INTERFACED TELETYPES. 



.ASECT 





.=0 






000000 


D.LNK: 


.BLKW 


1 


000002 


D.UCB: 


.BLKW 


1 


000004 


D.NAM: 


.BLKW 


1 


000006 


D.UNIT: 


.BLKB 


1 


000007 




• BLKB 


1 


000010 


D.UCBL: 


• BLKW 


1 


000012 


D.DSP: 


.BLKW 


1 


000014 


D.MSK: 


.BLKW 


1 


000016 




.BLKW 


1 


000020 




.BLKW 


1 


000022 




.BLKW 


1 


000024 




.BLKW 


1 


000026 




.BLKW 


1 


000030 




.BLKW 


1 


000032 




.BLKW 


1 


000034 


D.PCB: 


.BLKW 
.PSECT 


1 



LINK TO NEXT DCB 

POINTER TO FIRST UNIT CONTROL BLOCK 

GENERIC DEVICE NAME 

LOWEST UNIT NUMBER COVERED BY THIS DCB 

HIGHEST UNIT NUMBER COVERED BY THIS DCB 

LENGTH OF EACH UNIT CONTROL BLOCK IN BYTES 

POINTER TO DRIVER DISPATCH TABLE 

LEGAL FUNCTION MASK . CODES 0-15. 

CONTROL FUNCTION MASK CODES 0-15. 

NOP'ED FUNCTION MASK CODES 0-15. 

ACP FUNCTION MASK CODES 0-15. 

LEGAL FUNCTION MASK CODES 16.-31. 

CONTROL FUNCTION MASK CODES 16.-31. 

NOP'ED FUNCTION MASK CODES 16.-31. 

ACP FUNCTION MASK CODES 16.-31. 

LOADABLE DRIVER PCB ADDRESS 



DRIVER DISPATCH TABLE OFFSET DEFINITIONS 



D.VDEB=1 77776 

D.VINI=0 

D.VCAN=2 

D.VOUT=4 

D.VPWF=6 



DEALLOCATE INTERNAL BUFFERS (FD TTDRV) 

DEVICE INITIATOR 

CANCEL CURRENT I/O FUNCTION 

DEVICE TIMEOUT 

POWERFAIL RECOVERY 
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EPKDF$ 



EPKDF$ 



ERROR MESSAGE BLOCK DEFINITIONS 
.ASECT 



HEADER SUBPACKET 





.=0 






000000 


E$HLGH 


• BLKW 


1 


000002 


E$HSBF 


.BLKW 


1 


000004 


E$HSYS 


.BLKB 


1 


000005 


E$HIDN 


.BLKB 


1 


000006 


E$HSID 


• BLKB 


4 


000012 


E$HCTX 


.BLKB 


1 


000013 


E$HFLG 


.BLKB 


1 


000014 


E$HENS 


.BLKW 


1 


000016 


E$HERS 


.BLKW 


1 


000020 


E$HENC 






000020 


E $HTYC 


.BLKB 


1 


000021 


E$HTYS 


.BLKB 


1 


000022 


E$HTIM 


: .BLKB 


6 


000030 


E$HPTY 


.BLKB 


1 


000031 




.BLKB 


1 


000032 


E$HURM 


: .BLKW 
.EVEN 


1 

-L 


000034 


E$HLEN 







+ + 

I SUBPACKET LENGTH IN BYTES | 

+ + 

| SUBPACKET FLAGS | 

+ + + 

| FORMAT IDENTIFICATION | OPERATING SYSTEM CODE | 
+ + + 

| OPERATING SYSTEM IDENTIFICATION | 

I I 

+ + + 

| FLAGS | CONTEXT CODE | 

+ + + 

| ENTRY SEQUENCE | 

+ + 

| ERROR SEQUENCE | 

+ + + 

| ENTRY TYPE SUBCODE | ENTRY TYPE CODE | 

+ + + 

| TIME STAMP ! 

! I 

I I 

+ + + 

| RESERVED | PROCESSOR TYPE | 

+ + + 

| PROCESSOR IDENTIFICATION (URM) | 

+ + 



SUBPACKET LENGTH IN BYTES 

SUBPACKET FLAGS 

OPERATING SYSTEM CODE 

FORMAT IDENTIFICATION 

OPERATING SYSTEM IDENTIFICATION 

CONTEXT CODE 

FLAGS 

ENTRY SEQUENCE NUMBER 

ERROR SEQUENCE NUMBER 

ENTRY CODE 

ENTRY TYPE CODE 

ENTRY TYPE SUBCODE 

TIME STAMP 

PROCESSOR TYPE 

RESERVED 

PROCESSOR IDENTIFICATION (URM) 



; LENGTH 
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SUBPACKET FLAGS FOR ESHSBF 



SM.ERR 


1 


SM . HDR 


1 


SM.TSK 


2 


SM.DID 


4 


SM.DOP 


10 


SM . DAC 


20 


SM . DAT 


40 


SM.MBC 


= 20000 


SM.CMD 


= 40000 


SM . Z ER 


=100000 



ERROR PACKET 

HEADER SUBPACKET 

TASK SUBPACKET 

DEVICE IDENTIFICATION SUBPACKET 

DEVICE OPERATION SUBPACKET 

DEVICE ACTIVITY SUBPACKET 

DATA SUBPACKET 

22-BIT MASSBUS CONTROLLER PRESENT 

ERROR LOG COMMAND PACKET 

ZERO I/O COUNTS 



CODES FOR FIELD E$HIDN 

EHSFOR = 1 ; CURRENT PACKET FORMAT 



FLAGS FOR THE ERROR LOG FLAGS BYTE ($ERFLA) IN THE EXEC 



ES.INI = 

ES.DAT = 

ES.LIM = 

ES.LOG = 



1 ; ERROR LOG INITIALIZED 

2 ; ERROR LOG RECEIVING DATA PACKETS 
4 ; ERROR LIMITING ENABLED 



10 



ERROR LOGGING ENABLED 



TYPE AND SUBTYPE CODES FOR FIELDS E$HTYC AND E$HTYS 

SYMBOLS WITH NAMES E$CXXX ARE TYPE CODES FOR FIELD E$HTYC, 
SYMBOLS WITH NAMES E$SXXX ARE SUBTYPE CODES FOR FIELD E$HTYS. 



E$CCMD 
E$SSTA 
E$SSWI 
E$SAPP 
E$SBAC 
E$SSHO 
E$SCHL 

E$CERR 
E$SDVH 
E$SDVS 
E$STMO 
E$SUNS 

E$CDVI 
E$SDVI 

E$CDCI 
E$SMOU 
E$SDMO 
E$SRES 
E$SRCT 

E$CCPU 
E$SMEM 
E$SINT 

E$CSYS 
E$SPWR 



1 
1 
2 
3 
4 
5 
6 

2 

1 
2 
3 
4 

3 

1 

4 
1 
2 
3 
4 

5 
1 
2 

6 

1 



ERROR LOG CONTROL 

ERROR LOG STATUS CHANGE 

SWITCH LOGGING FILES 

APPEND FILE 

DECLARE BACKUP FILE 

SHOW 

CHANGE LIMITS 

DEVICE ERRORS 

DEVICE HARD ERROR 
DEVICE SOFT ERROR 
DEVICE INTERRUPT TIMEOUT 
DEVICE UNSOLICITED INTERRUPT 

DEVICE INFORMATION 

DEVICE INFORMATION MESSAGE 

DEVICE CONTROL INFORMATION 
DEVICE MOUNT 
DEVICE DISMOUNT 
DEVICE COUNT RESET 
BLOCK REPLACEMENT 

CPU DETECTED ERRORS 
MEMORY ERROR 
UNEXPECTED INTERRUPT 

SYSTEM CONTROL INFORMATION 
POWER RECOVERY 
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E$CCTL 


= 


7 


• CONTROL INFORMATION 




E$STIM 


= 


1 


TIME CHANGE 




E$SCRS 


= 


2 


SYSTEM CRASH 




E$SLOA 


= 


3 , 


DEVICE DRIVER LOAD 




E$SUNL 


= 


4 , 


DEVICE DRIVER UNLOAD 




E$SHRC 


= 


5 ; 


RECONFIGURATION STATUS CHANGE 




E$SMES 


= 


6 , 


MESSAGE 




E$CSDE 


= 


10 , 


SOFTWARE DETECTED EVENTS 




E$SABO 


= 


1 


; TASK ABORT 


; CODES 


FOR CONTEXT 


CODE 


ENTRY E$HCTX 




EH$NOR 


— 


i 


; NORMAL ENTRY 




EH$STA 


= 


2 


■ START ENTRY 




EH$CRS 


— 


3 


• CRASH ENTRY 


; CODES 


FOR FLAGS ENTRY E$HFLG 




EH$VIR 


= 


1 


; ADDRESSES ARE VIRTUAL 




EH$EXT 


= 


2 


; ADDRESSES ARE EXTENDED 




EH$COU 


= 


4 


• ERROR COUNTS SUPPLIED 



TASK SUBPACKET 



+ _ + 

| TASK SUBPACKET LENGTH | 

+ + 

| TASK NAME IN RAD50 I 

I I 

+ + 

| TASK UIC I 

+ + 

| TASK TI: DEVICE NAME I 

+ + + 

| FLAGS | TASK TI: UNIT NUMBER | 
+ + + 





.=0 










000000 


E$TLGH 


.BLKW 


1 




TASK SUBPACKET LENGTH 


000002 


E$TTSK 


• BLKW 


2 




TASK NAME IN RAD50 


000006 


E$TUIC 


.BLKW 


1 




TASK UIC 


000010 


E$TTID 


.BLKB 


2 




TASK TI: DEVICE NAME 


000012 


E$TTIU 


.BLKB 


1 




TASK TI: UNIT 


000013 


E$TFLG 


.BLKB 
• EVEN 


1 




• FLAGS 


000014 


E$TLEN 












; FLAGS 


3 FOR ENTRY 


E$TFLG 








ET$PRV 


— 


1 


; TASK IS PRIVILEGED 






ET$PRI 


= 


2 


• TERMINAL IS PRIVILEGE 
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DEVICE IDENTIFICATION SUBPACKET 
+ 



DEVICE IDENTIFICATION SUBPACKET LENGTH 



-+ 

! 
-+ 



| DEVICE MNEMONIC NAME 

+ + 

| CONTROLLER NUMBER | DEVICE UNIT NUMBER | 

+_„ + + 

| PHYSICAL SUBUNIT # | PHYSICAL UNIT # | 

+ + + 

| PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
+ + + 

| RESERVED | FLAGS I 

+ + + 

| VOLUME NAME OF MOUNTED VOLUME | 

I I 

I I 

I I 

I I 

I I 

+ + 

| PACK IDENTIFICATION I 

I I 

+ + 

| DEVICE TYPE CLASS I 

+ + 

| DEVICE TYPE I 

I I 

+ + 

| I/O OPERATION COUNT LONGWORD | 

I I 

+ + + 

| HARD ERROR COUNT | SOFT ERROR COUNT | 

+ + + 

| BLOCKS TRANSFERRED COUNT (RSX-11M-PLUS ONLY) | 



| CYLINDERS CROSSED COUNT (RSX-11M-PLUS ONLY) 

I 

+ 



.=0 
000000 E$ILGH: .BLKW 1 
000002 E$ILDV: .BLKW 1 

000004 E$ILUN: .BLKB 1 

000005 E$IPCO: .BLKB 1 

000006 E$IPUN: .BLKB 1 

000007 E$IPSU: .BLKB 1 

.IF DF R$$MPL 
E$IPDV: .BLKW 1 

.ENDC ; R$$MPL 



DEVICE IDENTIFICATION SUBPACKET LENGTH 

DEVICE MNEMONIC NAME 

DEVICE UNIT NUMBER 

CONTROLLER NUMBER 

PHYSICAL UNIT NUMBER 

PHYSICAL SUBUNIT NUMBER 



PHYSICAL DEVICE MNEMONIC 
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000010 


E$IFLG 


.BLKB 


1 


; FLAGS 


000011 




.BLKB 


1 


• RESERVED 


000012 


E$IVOL 


.BLKB 


12. 


; VOLUME NAME 


000026 


E$IPAK 


.BLKB 


4 


PACK IDENTIFICATION 


000032 


E$IDEV 






■ DEVICE TYPE 


000032 


E$IDCL 


.BLKW 


1 


DEVICE TYPE CLASS 


000034 


E$IDTY 


.BLKW 


2 


DEVICE TYPE 


000040 


E$I0PR 


• BLKW 


2 


I/O OPERATION COUNT LONGWORD 


000044 


E$IERS 


.BLKB 


1 


SOFT ERROR COUNT 


000045 


E$IERH 


.BLKB 


1 


HARD ERROR COUNT 



E$IBLK: 



.IF DF R$$MPL 

.BLKW 2 
.BLKW 2 

. ENDC ; R$$MPL 

.EVEN 



; BLOCKS TRANSFERRED COUNT 



000046 E$ILEN: 



:ylinders CROSSED 



SUBPACKET LENGTH 



)UN"i 



FLAGS FOR FIELD E$IFLG 

EI$SUB = 1 ; SUBCONTROLLER DEVICE 



DEVICE OPERATION SUBPACKET 

+ + 

| DEVICE OPERATION SUBPACKET LENGTH | 

+ + 

| TASK NAME IN RAD50 | 

I I 

+ + 

I TASK UIC | 

+ + 

| TASK TI: LOGICAL DEVICE MNEMONIC | 

+ + + 

| RESERVED | TASK TI: DEVICE UNIT | 

+ + + 

| I/O FUNCTION CODE | 

+ + + 

I RESERVED | OPERATION FLAGS | 
+ + + 

| TRANSFER OPERATION ADDRESS | 

I I 

+ + 

| TRANSFER OPERATION BYTE COUNT | 

+ + 

| CURRENT OPERATION RETRY COUNT | 

+ + 



SUBPACKET LENGTH 

TASK NAME IN RAD50 

TASK UIC 

TASK TI: LOGICAL DEVICE MNEMONIC 

TASK TI: LOGICAL DEVICE UNIT 

RESERVED 

I/O FUNCTION CODE 

OPERATION FLAGS 

RESERVED 





.=0 






000000 


E$OLGN: 


.BLKW 


1 


000002 


E$OTSK: 


.BLKW 


2 


000006 


E$OUIC: 


.BLKW 


1 


000010 


E$OTID: 


.BLKB 


2 


000012 


E$OTIU: 


. BLKB 


1 


000013 




• BLKB 


1 


000014 


E$OFNC: 


.BLKW 


1 


000016 


E$OFLG: 


.BLKB 


1 


000017 




.BLKB 


1 
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SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 



000020 E$OADD: 

000024 E$OSIZ: 

000026 E$ORTY: 

000030 E$0LEN: 



.BLKW 
.BLKW 
.BLKW 
.EVEN 



TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 
CURRENT OPERATION RETRY COUNT 

DEVICE OPERATION SUBPACKET LENGTH 



FLAGS FOR FIELD E$OFLG 



EO$TRA 
EO$DMA 
EO$EXT 
EO$PIP 



TRANSFER OPERATION 

DMA DEVICE 

EXTENDED ADDRESSING DEVICE 



10 ; DEVICE IS POSITIONING 



I/O ACTIVITY SUBPACKET 
+ 



I/O ACTIVITY SUBPACKET LENGTH 



.=0 
000000 E$ALGH: .BLKW 1 



; SUBPACKET LENGTH 



-+ 

I 

-+ 



I/O ACTIVITY SUBPACKET ENTRY 

+ 



| LOGICAL DEVICE NAME MNEMONIC I 

+ + + 

| CONTROLLER NUMBER | LOGICAL DEVICE UNIT | 

+ + + 

| PHYSICAL SUBUNIT # | PHYSICAL UNIT NUMBER | 
+ + + 

| PHYSICAL DEVICE MNEMONIC (RSX-1 1M-PLUS ONLY) | 
+ + + 

| TASK TI: LOGICAL UNIT | DEVICE FLAGS | 

+ + + 

| REQUESTING TASK NAME IN RAD50 I 



REQUESTING TASK UIC 



I TASK TI: LOGICAL DEVICE NAME 

+ - 

| I/O FUNCTION CODE 

+ + 

| RESERVED | FLAGS 

+ + 

| TRANSFER OPERATION ADDRESS 

I 

+ 

| TRANSFER OPERATION BYTE COUNT 
+ 



-+ 

I 
-+ 

I 

-+ 

I 
-+ 

I 

I 

-+ 

I 
-+ 
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000000 
000002 
000003 
000004 
000005 



.=0 

E$ALDV 

E$ALUN 

E$APC0 

E$APUN 

E$APSU 



E$APDV: 



• BLKW 
.BLKB 
.BLKB 
.BLKB 
.BLKB 



.IF DF R$$MPL 

.BLKW 1 

. ENDC ; R$$MPL 



000006 


E$ADFG: 


• BLKB 


1 


000007 


E$ATIU: 


.BLKB 


1 


000010 


E$ATSK: 


.BLKW 


2 


000014 


E$AUIC: 


.BLKW 


1 


000016 


E$ATID: 


• BLKW 


1 


000020 


E$AFNC: 


• BLKW 


1 


000022 


E$AFLG: 


.BLKB 


1 


000023 




• BLKB 


1 


000024 


E$AADD: 


• BLKW 


2 


000030 


E$ASIZ: 


.BLKW 
• EVEN 


1 


000032 


E$ALEN: 







LOGICAL DEVICE NAME MNEMONIC 
LOGICAL DEVICE UNIT 
CONTROLLER NUMBER 
PHYSICAL UNIT NUMBER 
PHYSICAL SUBUNIT NUMBER 



; PHYSICAL DEVICE MNEMONIC 



DEVICE FLAGS 

TASK TI: LOGICAL UNIT 

REQUESTING TASK NAME IN RAD50 

REQUESTING TASK UIC 

TASK TI: LOGICAL DEVICE NAME 

I/O FUNCTION CODE 

FLAGS 

RESERVED 

TRANSFER OPERATION ADDRESS 

TRANSFER OPERATION BYTE COUNT 

; SUB PACKET ENTRY LENGTH 



FLAGS FOR FIELD E$ADFG 

EA$SUB = 1 ; SUBCONTROLLER DEVICE 



FLAGS FOR FIELD E$AFLG 



EA$TRA 
EA$DMA 
EA$EXT 
EA$PIP 

.PSECT 



1 
2 

4 
10 



TRANSFER OPERATION 

DMA DEVICE 

DEVICE HAS EXTENDED ADDRESSING 

DEVICE IS POSITIONING 
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F11DF$ 



F11DF$ ,,SYSDEF 





; VOLUME CONTROL BLOCK 






.ASECT 






.=0 






000000 


V.TRCT: 


.BLKW 


l ; 






.IF DF 


R$$11M 


000002 


V.TYPE: 


.BLKB 


1 




VT.SL1= 


1 






VT.ANS= 


10 






VT.UNL= 


11 




000003 


V.VCHA: 


.BLKB 


1 ; 




VC.SLK= 


1 






VC.HLK= 


2 






VC.DEA= 


4 






VC.PUB = 


10 




000004 


V.LABL: 


.BLKB 


14 ; 


000020 


V. PKSR: 


.BLKW 


2 



TRANSACTION COUNT 



VOLUME TYPE DESCRIPTOR 

FILES-11 STRUCTURE LEVEL 1 

ANSI LABELED TAPE 

UNLABELED TAPE 

VOLUME CHARACTERISTICS 

CLEAR VOLUME VALID ON DISMOUNT 

UNLOAD THE VOLUME ON DISMOUNT 

DEALLOCATE THE VOLUME ON DISMOUNT 

SET (CLEAR) US. PUB ON DISMOUNT 

VOLUME LABEL (ASCII) 

PACK SERIAL NUMBER FOR ERROR LOGGING 



000024 V.SLEN: 



LENGTH OF SHORT VCB 







.ENDC 


;R$$11M 


000024 


V.IFWI: 


.BLKW 


l ; 






• IF DF 


R$$11D 




V. STD: 


.BLKW 


1 






.ENDC 


;R$$11D 


000026 
000032 
000033 
000034 
000036 
000040 


V.FCB: 
V.IBLB: 
V. IBSZ : 

V.FMAX: 
V.WISZ : 


.BLKW 
.BLKB 
.BLKB 
• BLKW 
.BLKW 
.BLKB 


2 

1 
1 
1 
1 

1 


000041 
000042 
000044 
000045 
000046 


V.SBCL: 
V.SBSZ : 
V. SBLB: 
V.FIEX: 


.BLKB 
.BLKW 
.BLKB 
.BLKB 
• BLKW 


1 ; 

1 
1 
1 



INDEX FILE WINDOW 



STD OF TASK CHARGED WITH NODE 



FILE CONTROL BLOCK LIST HEAD 
INDEX BIT MAP 1ST LBN HIGH BYTE 
INDEX BIT MAP SIZE IN BLOCKS 
INDEX BITMAP 1ST LBN LOW BITS 
MAX NO. OF FILES ON VOLUME 
DEFAULT SIZE OF WINDOW IN RTRV PTRS 
VALUE IS < 128. 

STORAGE BIT MAP CLUSTER FACTOR 
STORAGE BIT MAP SIZE IN BLOCKS 
STORAGE BIT MAP 1ST LBN HIGH BYTE 
DEFAULT FILE EXTEND SIZE 
STORAGE BIT MAP 1ST LBN LOW BITS 



.IF DF R$$11M 



000050 
000052 



V.VOWN: 
V.VPRO: 



.BLKW 1 
.BLKW 1 



VOLUME OWNER'S UIC 
VOLUME PROTECTION 



.ENDC ;R$$11M 



000054 


V.FPRO: 


.BLKW 


1 


000056 


V. FRBK: 


.BLKB 


1 


000057 


V.LRUC: 


.BLKB 


1 


000060 




.BLKW 


1 


000062 


V.STS: 


.BLKB 


1 




VS.IFW= 


1 






VS . BMW= 


2 





VOLUME DEFAULT FILE PROTECTION 

NUMBER OF FREE BLOCKS ON VOLUME HIGH BYTE 

COUNT OF AVAILABLE LRU SLOTS IN FCB LIST 

NUMBER OF FREE BLOCKS ON VOLUME LOW BITS 

VOLUME STATUS BYTE, CONTAINING THE FOLLOWING 

INDEX FILE IS WRITE ACCESSED 

STORAGE BITMAP FILE IS WRITE ACCESSED 
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000063 V.FFNU: .BLKB 1 

000064 V. EXT: .'BLKW 1 

000066 V.LGTH: 



FIRST FREE INDEX FILE BITMAP BLOCK 
POINTER TO VCB EXTENSION 

SIZE IN BYTES OF VCB 



000010 M.LEN: 



MOUNT LIST ENTRY 

EACH ENTRY ALLOWS ACCESS TO A SPECIFIED USER FOR A NON-PUBLIC DEVICE 

TO ALLOW EXPANSION, ONLY THE ONLY TYPE CODE DEFINED IS "1" FOR 
DEVICE ACCESS BLOCKS 



LINK WORD 

TYPE OF ENTRY 

MOUNTED VOLUME USER ACCESS LIST 

NUMBER OF ACCESSES 

DEVICE UCB 

ACCESSOR TI: UCB 

LENGTH OF ENTRY 







.ASECT 






.=0 






000000 


M.LNK: 


.BLKW 


1 


000002 


M.TYPE: 


.BLKB 


1 




MT.MLS= 


1 




000003 


M.ACC: 


.BLKB 


^ 


000004 


M.DEV: 


.BLKW 


1 


000006 


M.TI: 


.BLKW 


1 



000000 



FILE CONTROL BLOCK 



.=0 

F.LINK: 



F.FEXT: 
F.STD: 



, ASECT 



• BLKW 



, IF DF R$$11D 

.BLKW 1 
,BLKW 1 

, ENDC ;R$$11D 



000002 


F.FNUM 


: .BLKW 


1 


000004 


F.FSEQ 


.BLKW 


1 


000006 




.BLKB 


1 


000007 


F.FSQN 


.BLKB 


1 


000010 


F.FOWN 


.BLKW 


1 


000012 


F.FPRO 


.BLKW 


1 


000014 


F.UCHA 


.BLKB 


1 


000015 


F.SCHA 


.bLkb 


1 


000016 


F.HDLB 


.BLKW 


2 


000022 


F.LBN: 


.BLKW 


2 


000026 


F.SIZE 


.BLKW 


2 


000032 


F.NACS 


.BLKB 


1 


000033 


F.NLCK 


.BLKB 


1 



FCB CHAIN POINTER 



POINTER TO EXTENSION. FCB 

STD OF TASK CHARGED WITH NODE 



FILE NUMBER 

FILE SEQUENCE NUMBER 

NOT USED 

FILE SEGMENT NUMBER 

FILE OWNER'S UIC 

FILE PROTECTION CODE 

USER CONTROLLED CHARACTERISTICS 

SYSTEM CONTROLLED CHARACTERISTICS 

FILE HEADER LOGICAL BLOCK NUMBER 

BEGINNING OF STATISTICS BLOCK 

LBN OF VIRTUAL BLOCK 1 IF CONTIGUOUS 

IF NON CONTIGUOUS 

SIZE OF FILE IN BLOCKS 

NO. OF ACCESSES 

NO. OF LOCKS 
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000012 


S.STBK= 


. -F.LBN 




000034 


F.STAT: 






000034 


F . NWAC : 


.BLKB 


1 


000035 




.BLKB 


1 




FC.WAC= 


100000 






FC.DIR= 


40000 






FC.CEF= 


20000 






FC.FCO= 


10000 




000036 


F.DREF: 


.BLKW 


1 


000040 


F.DRNM: 


.BLKW 


1 






.IF DF 


R$$11M 


000042 


F.FEXT: 


.BLKW 


1 






.ENDC 


R$$11M 


000044 


F.FVBN: 


.BLKW 


2 


000050 


F.LKL: 


.BLKW 


1 


000052 


F.WIN: 


.BLKW 


1 


000054 


F.LGTH: 







SIZE OF STATISTICS BLOCK 

FCB STATUS WORD 

NUMBER OF WRITE ACCESSORS 

STATUS BITS FOR FCB CONSISTING OF 

SET IF FILE ACCESSED FOR WRITE 

SET IF FCB IS IN DIRECTORY LRU 

SET IF DIRECTORY EOF NEEDS UPDATING 

SET IF TRYING TO FORCE DIRECTORY CONTIG 

DIRECTORY EOF BLOCK NUMBER 

1ST WORD OF DIRECTORY NAME 



; POINTER TO EXTENSION FCB 



STARTING VBN OF THIS FILE SEGMENT 
POINTER TO LOCKED BLOCK LIST FOR FILE 
WINDOW BLOCK LIST FOR THIS FILE 

SIZE IN BYTES OF FCB 



WINDOW 



,ASECT 



.=0 
000000 W.ACT: 

000000 W.BLKS: 

000000 W.CTL: 



,BLKW 



WI.RDV= 400 

WI.WRV= 1000 

WI.EXT= 2000 

WI.LCK= 4000 

WI.DLK= 10000 

.IF DF R$$11M 

WI.PND= 20000 

.ENDC ;R$$11M 

WI.EXL= 40000 
WI.WCK= 100000 

.IF NDF R$$11M 



W.FCB: 


.BLKW 


1 


W.STD: 


.BLKW 


1 


W.VBN: 


• BLKB 


1 


W.WISZ : 


.BLKB 


1 




.BLKW 


1 


W.LKL: 


.BLKW 


1 


W.WIN: 


.BLKW 


1 


W.RTRV: 







NUMBER OF ACTIVE MAPPING POINTERS 

WHEN NO SECONDARY POOL 
BLOCK SIZE OF SECONDARY POOL SEGMENT 

WHEN SECONDARY POOL 
LOW BYTE = # OF MAP ENTRIES ACTIVE 
HIGH BYTE CONSISTS OF CONTROL BITS 
READ VIRTUAL BLOCK ALLOWED IE SET 
WRITE VIRTUAL BLOCK ALLOWED IF SET 
EXTEND ALLOWED IF SET 
SET IF LOCKED AGAINST SHARED ACCESS 
SET IF DEACCESS LOCK ENABLED 



WINDOW TURN PENDING BIT 



SET IF MANUAL UNLOCK DESIRED 
DATA CHECK ALL WRITES TO FILE 

IF NOT RSX-11 

FILE CONTROL BLOCK ADDRESS 

STD OF TASK CHARGED WITH WIDOW NODE 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

POINTER TO LIST OF USERS LOCKED BLOCKS 

WINDOW BLOCK LIST LINK WORD 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 
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000002 W.IOC: 
000003 

000004 W.FCB 

000006 W.LKL 

000010 W.WIN 



.IFF 

.BLKB 1 

.BLKB 1 

.BLKW 1 

.BLKW 1 

.BLKW 1 

.IF NB SYSDEF 

.IF NDF P$$WND 



; IF RSX-11 

; COUNT OF I/O THROUGH THIS WINDOW 

; RESERVED 

; FILE CONTROL BLOCK ADDRESS 

; POINTER TO LIST OF USERS LOCKED BLOCKS 

; WINDOW BLOCK LIST LINK WORD 

; IF SYSDEF SPECIFIED IN CALL 

; IF SECONDARY POOL WINDOWS NOT ALLOWED 



NON-SECONDARY POOL WINDOW BLOCK 

IF SECONDARY POOL WINDOWS ARE NOT ENABLED, THE WINDOW BLOCK 
CONTAINS THE CONTROL INFORMATION AND RETRIEVAL POINTERS. 



HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

DEFINE LABEL WITH ODD ADDR TO CATCH BAD REFS 

SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 



000012 


W.VBN: 


.BLKB 


1 


000013 


W.MAP: 






000013 


W.WISZ: 


.BLKB 


1 


000014 




.BLKW 


1 


000016 


W.RTRV: 







, IFF 



IF WINDOWS IN SECONDARY POOL 



SECONDARY POOL WINDOW CONTROL AND MAPPING BLOCK 

IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, LUTN2 POINTS 
TO A CONTROL BLOCK IN SYSTEM POOL WHICH CONTAINS THE 
FOLLOWING CONTROL FIELDS AND THE MAPPING INFORMATION 
FOR THE SECONDARY POOL WINDOW. 



W.MAP: 



.BLKW 



1 



ADDR TO THE MAPPING PTRS IN SECONDARY POOL 



SECONDARY POOL WINDOW 

IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, THE RETRIEVAL 
POINTERS ARE MAINTAINED IN SECONDARY POOL IN THE FOLLOWING 
FORMAT. 



.=0 





ASSUME 


W 




• BLKB 


1 


W.USE: 


.BLKB 


1 


W.VBN: 


.BLKB 


1 


W.WISZ : 


• BLKB 


1 




.BLKW 


1 



.CTL,0 



W.RTRV: 



, ENDC ;P$$WND 



NUMBER OF ACTIVE MAPPING POINTERS 

STATUS OF BLOCK 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 

END SECONDARY POOL WINDOW CONDITIONAL 



•ENDC ;SYSDEF ; END SYSDEF CONDITIONAL 
.ENDC ;R$$11M ; END RSX-11M CONDITIONAL 



LOCKED BLOCK LIST NODE 



, ASECT 





.=0 






000000 


L.LNK: 


.BLKW 


1 


000002 


L.WI1: 


.BLKW 


1 



LINK TO NEXT NODE IN LIST 
POINTER TO WINDOW FOR FIRST ENTRY 
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IF DF R$$11D 



L.STD: 


.BLKW 


1 


L.VB1: 


.BLKW 


2 


L.VB2: 


.BLKW 


2 


L.CNT: 


.BLKB 


1 




-BLKB 


1 



POINTER TO STD OF TASK NODE CHARGED TO 
STARTING VBN OF FIRST ENTRY 
STARTING VBN OF SECOND ENTRY 
COUNT FOR FIRST ENTRY 
COUNT FOR SECOND ENTRY 



IFF 



000004 L.VB1: 

000005 L.CNT: 
000006 



,BLKB 1 
.BLKB 1 
.BLKW 1 



HIGH ORDER VBN BYTE 
COUNT FOR ENTRY 
LOW ORDER VBN 



000010 L.LKSZ: 



ENDC ;R$$11D 



PSECT 
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HDRDF$ 



HDRDP$ 



TASK HEADER OFFSET DEFINITIONS 



,ASECT 





.=0 






000000 


H.CSP: 


.BLKW 


1 


000002 


H.HDLN 


.BLKW 


1 


000004 


H.EFLM 


: .BLKW 


2 


000010 


H.CUIC 


.BLKW 


1 


000012 


H.DUIC 


: .BLKW 


1 


000014 


H.IPS: 


.BLKW 


1 


000016 


H.IPC: 


.BLKW 


1 


000020 


H.ISP: 


• BLKW 


1 


000022 


H.ODVA 


.BLKW 


1 


000024 


H.ODVL 


.BLKW 


1 


000026 


H . TKVA 


.BLKW 


1 


000030 


H . TKVL 


.BLKW 


1 


000032 


H.PFVA 


.BLKW 


1 


000034 


H.FPVA 


• .BLKW 


1 


000036 


H.RCVA 


.BLKW 


1 


000040 


H.EFSV 


.BLKW 


1 


000042 


H.FPSA 


• BLKW 


1 


000044 


H.WND: 


• BLKW 


1 


000046 


H.DSW: 


.BLKW 


1 


000050 


H.FCS: 


.BLKW 


1 


000052 


H.FORT- 


.BLKW 


1 


000054 


H.OVLY: 


.BLKW 


1 


000056 


H.VEXT: 


.BLKW 


1 


000060 


H.SPRI: 


.BLKB 


1 


000061 


H.NML: 


.BLKB 


1 


000062 


H . RRVA 


.BLKW 


1 


000064 


H.X25: 


.BLKB 


1 


000065 




• BLKB 


1 


000066 




.BLKW 


2 


000072 


H.GARD: 


.BLKW 


1 


000074 


H.NLUN: 


.BLKW 


1 


000076 


H.LUN: 


• BLKW 


2 



CURRENT STACK POINTER 

HEADER LENGTH IN BYTES 

EVENT FLAG MASK WORD AND ADDRESS 

CURRENT TASK UIC 

DEFAULT TASK UIC 

INITIAL PROCESSOR STATUS WORD (PS) 

INITIAL PROGRAM COUNTER (PC) 

INITIAL STACK POINTER (SP) 

ODT SST VECTOR ADDRESS 

ODT SST VECTOR LENGTH 

TASK SST VECTOR ADDRESS 

TASK SST VECTOR LENGTH 

POWER FAIL AST CONTROL BLOCK ADDRESS 

FLOATING POINT AST CONTROL BLOCK ADDRESS 

RECIEVE AST CONTROL BLOCK ADDRESS 

EVENT FLAG ADDRESS SAVE ADDRESS 

POINTER TO FLOATING POINT/EAE SAVE AREA 

POINTER TO NUMBER OF WINDOW BLOCKS 

TASK DIRECTIVE STATUS WORD 

FCS IMPURE POINTER 

FORTRAN IMPURE POINTER 

OVERLAY IMPURE POINTER 

WORK AREA EXTENSION VECTOR POINTER 

PRIORITY DIFFERENCE FOR SWAPPING 

NETWORK MAILBOX LUN 

RECEIVE BY REFERENCE AST CONTROL BLOCK ADDRESS 

FOR USE BY X. 25 SOFTWARE 

FIVE RESERVED BYTES 

POINTER TO HEADER GUARD WORD 

NUMBER OF LUN ' S 

START OF LOGICAL UNIT TABLE 
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LENGTH OF FLOATING POINT SAVE AREA 
H.FPSL=25.*2 





; WINDOW BLOCK 


OF 


000000 


!=0 
W.BPCB 


.BLKW 


1 


000002 


W.BLVR 


.BLKW 


1 


000004 


W.BHVR 


.BLKW 


1 


000006 


W . BATT 


.BLKW 


1 


000010 


W.BSIZ 


: .BLKW 


1 


000012 


W.BOFF 


: .BLKW 


1 


000014 


W.BFPD 


: .BLKB 


1 


000015 


W.BNPD 


.BLKB 


1 


000016 


W.BLPD 


• .BLKW 


1 



000020 W.BLGH: 



PARTITION CONTROL BLOCK ADDRESS 
LOW VIRTUAL ADDRESS LIMIT 
HIGH VIRTUAL ADDRESS LIMIT 
ADDRESS OF ATTACHMENT DESCRIPTOR 
SIZE OF WINDOW IN 32W BLOCKS 
PHYSICAL MEMORY OFFSET IN 32W BLOCKS 
FIRST PDR ADDRESS 
NUMBER OF PDR'S TO MAP 
CONTENTS OF LAST PDR 

LENGTH OF WINDOW DESCRIPTOR 



PSECT 
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HWDDF$ 



HWDDF$ 



HARDWARE REGISTER ADDRESSES AND STATUS CODES 



MPCSR=177746 

MPAR=172100 

PIRQ=177772 

PR 0=0 

PR1=40 

PR4=200 

PR5=240 

PR6=300 

PR 7=3 40 

PS=i 77776 

SWR=1 77570 

TPS=177564 



ADDRESS OF PDP-11/70 MEMORY PARITY REGISTER 

ADDRESS OF FIRST MEMORY PARITY REGISTER 

PROGRAMMED INTERRUPT REQUEST REGISTER 

PROCESSOR PRIORITY 

PROCESSOR PRIORITY 1 

PROCESSOR PRIORITY 4 

PROCESSOR PRIORITY 5 

PROCESSOR PRIORITY 6 

PROCESSOR PRIORITY 7 

PROCESSOR STATUS WORD 

CONSOLE SWITCH AND DISPLAY REGISTER 

CONSOLE TERMINAL PRINTER STATUS REGISTER 



EXTENDED ARITHMETIC ELEMENT REGISTERS 
.IF DF E$$EAE 



AC=177302 
MQ=177304 
SC=177310 



ENDC ;E$$EAE 



; ACCUMULATOR 

; MULTIPLIER-QUOTIENT 

; SHIFT COUNT 



MEMORY MANAGEMENT HARDWARE REGISTERS AND STATUS CODES 
.IF DF M$$MGE 



KDSAR0= 
KDSDR0= 
KISAR0= 
KINAR0= 
KISAR5= 
KINAR5= 
KISAR6 = 
KINAR6= 
KISAR7= 
KINAR7= 
KISDR0= 
KISDR6= 
KISDR7= 
SISDR0= 
UDSAR0= 
UDSDR0= 
UISAR0= 
UISAR4= 
UISAR5= 
UISAR6 = 
UISAR7= 
UISDR0= 



=172360 
=172320 
=172340 
=KISAR0 
=172352 
=KISAR5 
=172354 
=KISAR6 
=172356 
=KISAR7 
=172 300 
=172314 
=172316 
=172200 
=177660 
=177620 
=177640 
= 177650 
=177652 
=177654 
=177656 
=177600 



KERNEL 


D 


PAR 





KERNEL 


D 


PDR 





KERNEL 


I 


PAR 





KERNEL 


I 


PAR 





KERNEL 


I 


PAR 


5 


KERNEL 


I 


PAR 


5 


KERNEL 


I 


PAR 


6 


KERNEL 


I 


PAR 


6 


KERNEL 


I 


PAR 


7 


KERNEL 


I 


PAR 


7 


KERNEL 


I 


PDR 





KERNEL 


I 


PDR 


6 


KERNEL 


I 


PAR 


7 


SUPERVISOR I 


PDR 


USER D 


PAR 




USER D 


PDR 




USER I 


PAR 




USER I 


PAR 4 




USER I 


PAR 5 




USER I 


PAR 6 




USER I 


PAR 7 




USER I 


PDR 
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UISDR 
UISDR 
UISDR 
UISDR 
UBMPR 
CMODE 
PMODE 
SR0=1 
SR3=1 



4=177610 

5=177612 

6=177614 

7=177616 

=170200 

=140000 

=30000 

77572 

72 516 



USER I PDR 4 

USER I PDR 5 

USER I PDR 6 

USER I PDR 7 

UNIBUS MAPPING REGISTER 

CURRENT MODE FIELD OF PS WORD 

PREVIOUS MODE FIELD OF PS WORD 

SEGMENT STATUS REGISTER 

SEGMENT STATUS REGISTER 3 



ENDC ;M$$MGE 



FEATURE SYMBOL DEFINITIONS 



FE.EXT: 
FE.MUP; 
FE. EXV= 
FE.DRV= 
FE.PLA= 
FE.CAL; 
FE.PKT; 
FE.EXP; 
FE.LSI; 
FE.OFF- 
FE.FDT: 
FE.X25: 
FE.DYM' 
FE.CEX; 
FE.MXT: 
FE.NLG 



=1 

=2 

=4 

=10 

=20 

=4 

=100 

=200 

=4 00 

=1000 

=2000 

=4000 

=10000 

=20000 

=40000 

=100000 



2 2 -BIT EXTENDED MEMORY SUPPORT 

MULTI-USER PROTECTION SUPPORT 

EXECUTIVE IS SUPPORTED TO 20K 

LOADABLE DRIVER SUPPORT 

PLAS SUPPORT 

DYNAMIC CHECKPOINT SPACE ALLOCATION 

PREALLOCATION OF I/O PACKETS 

EXTEND TASK DIRECTIVE SUPPORTED 

PROCESSOR IS AN LSI-11 

PARENT OFFSPRING TASKING SUPPORTED 

FULL DUPLEX TERMINAL DRIVER 

X. 25 COM EXECUTIVE LOADED (1=YES) 

DYNAMIC MEMORY ALLOCATION SUPPORTED 

COM EXEC IS LOADED 

MCR EXIT AFTER EACH COMMAND MODE 

LOGINS DISABLED - MULTI-USER SUPPORT 



SECOND FEATURE MASK SYMBOL DEFINITIONS 



F2.DAS = 

F2.LIB = 

F2.MP=4 

F2.EVT = 

F2.ACN= 

F2.SDW= 

F2.POL = 

F2.WND= 

F2.DPR= 

F2.IRR= 

F2.GGF= 

F2.RAS=. 

F2.AHR= 

F2.RBN 

F2.SWP= 

F2.STP= 



1 
2 

10 

20 

40 

100 

200 

400 

1000 

2000 

4000 

10000 

20000 

40000 

100000 



KERNEL DATA SPACE (M-PLUS ONLY) 

SUPERVISOR MODE LIBRARIES " 

MULTIPROCESSING SUPPORT " 

EVENT TRACE SUPPORT 
CPU ACCOUNTING 

SHADOW RECORDING " 

SECONDARY POOLS " 

SECONDARY POOL FILE WINDOWS 
DIRECTIVE PARTITION SUPPORT 
INSTALL, REQUEST AND REMOVE SUPPORT 
GROUP GLOBAL EVENT FLAG SUPPORT 
RECEIVE/SEND DATA PACKET SUPPORT 
ALT. HEADER REFRESH AREAS SUPPORTED 
ROUND ROBIN SCHEDULING SUPPORT 
EXECUTIVE LEVEL DISK SWAPPING SUPPORT 
EVENT FLAG MASK IS IN THE TCB (1=YES) 
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THIRD FEATURE MASK SYMBOL DEFINITIONS 



F3.CRA= 
F3.NWK= 
F3.EIS = 
F3.STM = 
F3.UDS = 
F3.PRO = 
F3.XHR= 
F3.AST= 
F3.11S = 
F3.CLI = 
F3.TCM= 
F3.PMN= 
F3.WAT= 
F3.RLK= 



=1 

=2 

=4 

dO 

=20 

■40 

=100 

=200 

=400 

=1000 

2000 

=4000 

=10000 

20000 



SPONTANEOUS CRASH (1=YES) 
SYSTEM HAS NETWORK SUPPORT 
SYSTEM REQUIRES THE EXTENDED INST. SET 
SYSTEM HAS SET SYSTEM TIME DIRECTIVE 
USER DATA SPACE (M-PLUS ONLY) 
PROTO TCBS OUT OF POOL " 
EXTERNAL HEADER SUPPORT " 
SYSTEM HAS AST SUPPORT 
SYSTEM IS RSX-11S 
SYSTEM HAS MULTIPLE CLI SUPPORT 
TERMINAL COMMON (M-PLUS ONLY) 
POOL MONITORING SUPPORT 
WATCHDOG TIMER SUPPORT 
■RMS 1 RECORD LOCKING SUPPORT 



HARDWARE FEATURE MASK SYMBOL DEFINITIONS 



HF.UBM=1 
HF.EIS=2 
HF.CIS=200 
HF.FPP=100000 



SYSTEM HAS A UNIBUS MAP (1=YES) 

SYSTEM HAS EXTENDED INSTRUCTION SET 

SYSTEM HAS COMMERCIAL INSTRUCTION SET 

SYSTEM SUPPORTS FLOATING POINT (l=NO) 
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ITBDF$ 



ITBDF$ ,,SYSDEF 



INTERRUPT TRANSFER BLOCK (ITB) OFFSET DEFINITIONS 
.IF DF A$$TRP 

DEFINE AST BLOCK OFFSETS 







.MCALL 


PKTDF$ 






PKTDF$ 








.ENDC 


;A$$TRP 






.ASECT 






.=0 






000000 


X.LNK: 


.BLKW 


1 


000002 


X. JSR: 


JSR 


R5,@#0 


000006 


X.PSW: 


.BLKB 


1 


000007 




.BLKB 


1 


000010 


X.ISR: 


• BLKW 


1 


000012 


X.FORK: 






000012 




.BLKW 


1 


000014 




• BLKW 


1 


000016 




.BLKW 


1 


000020 




.BLKW 


1 






.IF DF 


M$$MGE 




X.REL: 


.BLKW 


1 






.ENDC 


?M$$MGE 




X.DSI: 


• BLKW 


1 




X.TCB: 


.BLKW 


1 



IF NB SYSDEF 
IF DF A$$TRP 



X.AST: 



X.VEC: 

X.VPC: 
X.LEN: 



.BLKW 
,BLKB 



1 
A.PRM 



, ENDC ;A$$TRP 
, BLKW 1 

,BLKW 1 

.ENDC ; SYSDEF 
. PSECT 



LINK WORD FOR ITB LIST STARTING IN TCB 

CALL $INTSC 

LOW BYTE OF PSW FOR ISR 

UNUSED 

ISR ENTRY POINT (APR5 MAPPING) 

FORK BLOCK 

THREAD WORD 

FORK PC 

SAVED R5 

SAVED R4 



RELOCATION BASE FOR ARR5 



ADDRESS OF DIS.INT. ROUTINE 
TCB ADDRESS OF OWNING TASK 



A.DQSR FOR AST BLOCK 
AST BLOCK 



VECTOR ADDRESS (IF AST SUPPORT, 
THIS IS FIRST AND ONLY AST PARAMETER) 
SAVED VECTOR PC 
LENGTH IN BYTES OF ITB 
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LCBDF$ 



LCBDF$ 



LOGICAL ASSIGNMENT CONTROL BLOCK 

THE LOGICAL ASSIGNMENT CONTROL BLOCK (LCB) IS USED TO ASSOCIATE A 
LOGICAL NAME WITH A PHYSICAL DEVICE UNIT. LCB'S ARE LINKED TOGETHER 
TO FORM THE LOGICAL ASSIGNMENTS OF A SYSTEM. ASSIGNMENTS MAY BE ON 
A SYSTEM WIDE OR LOCAL (TERMINAL) BASIS. 

.ASECT 

LINK TO NEXT LCB 

LOGICAL NAME OF DEVICE 

LOGICAL UNIT NUMBER 

TYPE OF ENTRY (0=SYSTEM WIDE) 

TI UCB ADDRESS 

ASSIGNMENT UCB ADDRESS 

; LENGTH OF LCB 





.=0 






000000 


L.LNK: 


.BLKW 


1 


000002 


L . NAM : 


.BLKW 


1 


000004 


L.UNIT: 


.BLKB 


1 


000005 


L.TYPE: 


• BLKB 


1 
J. 


000006 


L.UCB: 


.BLKW 


1 


000010 


L.ASG: 


.BLKW 


1 


000012 


L.LGTH= 


-L.LNK 
.PSECT 
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MTADF$ 



MTADF$ 



ANSI MAGTAPE SPECIFIC DATA STRUCTURES 

VOLUME SET CONTROL BLOCK OFFSET DEFINITIONS (VSCB) 

VOLUME SET AND PROCESS CONTROL SECTION 



.ASECT 





• =0 






000000 


V.TCNT: 


.BLKW 


1 


000002 


V.TYPE: 


.BLKB 


1 


000003 


V.VCHA: 


.BLKB 


1 


000004 


V.LABL: 


.BLKB 


12 


000020 


V.NXT: 


• BLKW 


1 


000022 


V.MVL: 


.BLKW 


1 


000024 


V.UVL: 


.BLKW 


1 


000026 


V.ATL: 


• BLKW 


1 


000030 


V. UCB: 


.BLKW 


1 


000032 


V.RVOL: 


.BLKB 


1 


000033 


V.MOU: 


.BLKB 


1 


000034 


V.TCHR: 


.BLKW 


1 


000036 


V. SEQN: 


.BLKW 


1 


000040 


V. SECN: 


.BLKW 


1 


000042 


V.TPOS: 


.BLKB 


1 


000043 


V. PSTA: 


.BLKB 


1 


000044 


V.TIMO: 


.BLKW 


1 


000046 


V. STAT: 


.BLKW 


3 


000054 


V. TRTB : 


.BLKB 


1 


000055 


V.EFTV: 


.BLKB 


1 




; LABEL 


DATA SECTI 


000056 


V.BLKL: 


.BLKW 


1 


000060 


V.RECL: 


.BLKW 


1 


000062 


V.FNAM: 


.BLKW 


3 


000070 


V.FTYP: 


.BLKW 


1 


000072 


V.FVER: 


.BLKW 


1 


000074 


V.CDAT: 


.BLKW 


2 


000100 


V. EDAT: 


.BLKW 


2 


000104 


V.BLKC: 


.BLKW 


2 


000110 


V.RTYP: 


.BLKB 


1 


000111 


V.FATT: 


.BLKB 


1 


000112 




.BLKB 


30 



TRANSACTION COUNT 

VOLUME TYPE DESCRIPTOR 

VOLUME CHARACTERISTICS 

FILE SET ID (FIRST SIX BYTES) 

PTR TO NEXT VSCB NODE 

PTR TO MOUNTED VOL LIST 

PTR TO UNMOUNTED VOL LIST 

ATL ADDR OF ACCESSING TASK TCB IN RSX11M 

ADDR OF CURRENT UCB OR PUD 

CURRENT RELATIVE VOL # 

MOUNT MODE BYTE 

UINT CHAR. FOR ALL UNITS USED FOR VOL SET 

CURRENT FILE SEQUENCE # 

CURRENT FILE SECTION # 

POSITION OF TAPE IN TM'S TO NXT HDR1 

PROCESS STATUS BYTE 

BLOCKED PROCESS TIMEOUT COUNTER 

STATUS WORDS USED BY COMMAND EXECUTION MODULES 

TRANSLATION CONTROL BYTE 

FOR MAG TO RETURN IE. EOF, EOT, EOV 



BLOCK LENGTH 

RECORD LENGTH 

FILE NAME 

FILE TYPE 

FILE VERSION # 

CREATION DATE 

EXPRIATION DATE 

BLOCK COUNT FOR FILE SECTION 

RECORD TYPE 

FILE ATTRIBUTES FOR CARRIAGE CONTROL 

REMAINDER OF FILE ATTRIBUTES 
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; NULL 


WINDOW 


SECT 


000150 


V.WIND 


. .BLKW 


4. 


000160 


V.MST2 


.BLKW 


1 


000162 


V.FABY 


.BLKB 


1 


000163 




.BLKB 


1 


000164 


V.ANSN 


.BLKB 


17 


000205 


V.BOFF 


: .BLKB 


1. 


000206 


V.DENS 


• BLKB 


1. 


000207 


V.DRAT 


.BLKB 


1. 


000210 


V.DBLK 


.BLKW 


1. 


000212 


V. DREC 


.BLKW 


1. 






— • 

• PSECT 





NULL WINDOW 

MAGTAPE STATUS BITS 

FILE ACCESSIBILITY BYTE (HDR1) 

SPARE 

ANSI 17 CHARACTER FILE NAME 

BUFFER OFFSET 

REQUESTED UNIT DENSITY 

DEFAULT RECORD ATTRIBUTES 

DEFAULT BLOCK SIZE 

DEFAULT RECORD SIZE 

;SIZE OF VSCB 



DEFINE OFFSETS INTO NULL WINDOW SECTION 



, ASECT 



.=0 
000000 W.CTL: 



BLKW 1 
V.WINC=V.WIND4W.CTL 



.PSECT 



; CONTROL WORD IN WINDOW 
;CNTRL WORD IN NULL WINDOW 
; RELATIVE TO THE VSCB 



MOUNTED VOLUME LIST OFFSET DEFININTIONS (MVL) 
.ASECT 



.=0 



000000 M.NXT: 



000010 
000011 
000012 
000014 



M.NXT: 



M.RVOL 
M.STAT 
M.VIDP 
M.UCB: 



.IF DF R$$11M 
.BLKW 1 
.ENDC ;R$$11M 



000002 


M.UIC: 


.BLKW 


1 


000004 


M.CH: 


.BLKW 


1 


000006 


M.PROT: 


.BLKW 


1 



IF NDF R$$11M 



,BLKW 
.BLKW 



.ENDC ;R$$11M 



.BLKB 

• BLKB 
.BLKW 

• BLKW 



000016 S.MVL=. 



;PTR TO NXT MVL NODE (11M) 



; OWNER UIC FROM RVOL #1 
;U.CH/U.VP (11D) 
.-PROTECTION U.AR IN 11D 



;ACP WORDS 11D 

;PTR TO NEXT MVL NODE (11D) 



RELATIVE VOL # OF MOUNTED VOLUME 

VOLUME STATUS 

VOLUME ID POINTER 

ADDR OF ASSOC UCB OR PUD 

;SIZE OF MVL NODE 
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UNMOUNTED VOLUME AND VOLUME LIST OFFSET DEFINITIONS (UVL) 



, ASECT 





.=0 






000000 


L.NXT: 


.BLKW 


1 


000002 


L.VOL1 


.BLKB 


-t 

X 


000003 


L.VOL2 


.BLKB 


1 


000004 


L.VID1 


.BLKB 


6 


000012 


L.VID2 


.BLKB 


6 


000020 


S.UVL= 







PSECT 



PTR TO NXT UVL NODE 
REL VOL # OF l'ST VOL IN NODE 
REL VOL # OF 2'ND VOL IN NODE 
VOL ID OF l'ST VOL IN NODE 
VOL ID OF 2'ND VOL IN NODE 



;SIZE OF UVL NODE 



; SYSTEM DATA STRUCTURE CONTENT VALUES 



; VSCB VALUES 
; V.MOU VALUES 



VM.OLD 


= 


200 


VM.BYP 


= 


100 


VM.ULB 


= 


40 


VM.FSC 


= 


20 


VM.EXC 


— 


10 


'; V.MST2 VALUES 




V2.INI 


= 


1 


V2.XH2 


= 


2 


V2.XH3 


= 


4 


V2.NH3 


= 


10 


V2.0AC 


— 


20 


• V.PSTA VALUES 


- UNBL( 


VP.RM 


= 


2 


VP.WM 


= 


4 


VP.UCM 


= 


6 


VP.SM 


= 


10 


VP.MOU 


= 


20 


VP . RWD 


= 


40 


VP.VFY 


= 


VP.RWD 


VP.POS 


= 


100 



OLD .FL300 VOLUME — VM.BYP WILL ALSO BE SET 

BYPASS LABEL PROCESSING 

UNLABELED TAPE 

OVERRIDE FILE SET ID CHECK 

OVERRIDE EXPRIATION DATE CHECK 



MAG WANTS US TO INITIALIZE NEXT OUTPUT 
THIS FILE HAS NO HDR2, DON'T WRITE E0F2 
THIS FILE HAS NO HDR3, DON'T WRITE EOF3 
DON'T WRITE HDR3/EOX3 LABELS 
OVERRIDE FILE/VOLUME ACCESSIBILITY 



UNBLOCKED TRANSITION STATE 



READ DATA MODE 

WRITE DATA MODE 

UNLABELLED CREATE POSITIONING MODE 

SEARCH MODE 

MOUNT MODE 

REWIND OR VOL VERIFICATION WAIT 



; PROCESS IN POSITIONING MODE 
; (MULTI-SECTION FILE) 



BLOCKED STATE = -(UNBLOCKED TRANSITION STATE VALUES) 
PROCESS TIMED OUT BIT = 1 
VP.TO=l 
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NULL WINDOW CONTROL BIT DEFINITIONS 



WI.RDV = 

WI.WRV = 

WI.EXT = 

WI.LCK = 



400 

1000 

2000 

4000 



ACCESSED FOR READ 
ACCESSED FOR WRITE 
ACCESSED FOR EXTEND 
LOCKED 



MVL VALUES IN THE M.STAT FIELD 



MS.VER = 

MS. RID = 

MS.NMO = 

MS.TMO = 

MS. EXP = 



200 

1 
2 
4 
10 



VOL ID NOT VERIFIED 
VOL ID TO BE READ NOT CHECKED 
MOUNT MESSAGE NOT GIVEN YET 
ONE TIMEOUT ALREADY EXPRIED 
EXPIRATION DATE MESSAGE GIVEN 



MISC BITS USED IN MOUNT (STORED IN V. STS) 



MO.OVR 
MO.UIC 
MO. PRO 
MO. 160 



1 
2 
4 
10 



OVER RIDE VOL NAME SWITCH 
EXPLICIT UIC GIVEN 
EXPLICIT PROTECTION GIVEN 
1600 BPI SPECIFIED 
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PCBDF$ 



PCBDF$ , ,SYSDEF 



PARTITION CONTROL BLOCK OFFSET DEFINITIONS 



.ASECT 





.=0 






000000 


P.LNK: 


.BLKW 


1 


000002 


P.PRI: 


.BLKB 


1 


000003 


P. IOC: 


.BLKB 


1 


000004 


P . NAM : 


.BLKW 


2 


000010 


P. SUB: 


.BLKW 


1 


000012 


P. MAIN: 


.BLKW 


1 






.IF NB 


SYSDEF 






.IF NDF 


M$$MGE 



LINK TO NEXT PARTITION PCB 
PRIORITY OF PARTITION 
I/O + I/O STATUS BLOCK COUNT 
PARTITION NAME IN RAD50 
POINTER TO NEXT SUBPARTITION 
POINTER TO MAIN PARTITION 



P.HDR: 



;POINTER TO HEADER CONTROL BLOCK 







.ENDC 


;M$$MGE 






.IFTF 




000014 


P.REL: 


.BLKW 


1 


000016 


P.BLKS: 






000016 


P. SIZE: 


.BLKW 


1 


000020 


P. WAIT: 


.BLKW 


1 


000022 


P.SWSZ: 


.BLKW 


1 


000024 


P. BUSY: 


.BLKB 


2 


000026 


P. OWN: 






000026 


P.TCB: 


.BLKW 


1 


000030 


P.STAT: 


.BLKW 
.IFT 


1 






.IF DF 


M$$MGE 




P.HDR: 


.BLKW 


1 






.ENDC 


;M$$MGE 




P. PRO: 


.BLKW 


1 




P . ATT : 


.BLKW 


2 



; STARTING PHYSICAL ADDRESS OF PARTITION 

SIZE OF PARTITION IN: 

UNMAPPED SYSTEMS - BYTES 

MAPPED SYSTEMS - 32 WORD BLOCKS 

PARTITION WAIT QUEUE LISTHEAD (2 WORDS) 

PARTITION SWAP SIZE {SYSTEM ONLY) 

PARTITION BUSY FLAGS 

;TCB ADDRESS OF OWNER TASK 
; PARTITION STATUS FLAGS 



; POINTER TO HEADER CONTROL BLOCK 



; PROTECTION WORD [DEWR, DEWR, DEWR, DEWR] 
;ATTACHMENT DESCRIPTOR LISTHEAD 



.IF NDF P$$LAS 
P.LGTH=P.PRO 



;LENGTH OF PARTITION CONTROL BLOCK 
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P.LGTH=. 



IFF 

.ENDC ;P$$LAS 

.IFF 

• PSECT 



;LENGTH OF PARTITION CONTROL BLOCK 



PARTITION STATUS WORD BIT DEFINITIONS 



PS. OUT = 
PS.CKP= 
o,\, Art = 
PS.CHK= 
PS.FXD= 
PS.PER= 
PS.LIO= 
PS.NSF= 
PS.COM= 
PS.PIC= 
PS.SYS-- 
PS . DRV= 
PS.DEL= 



100000 

40000 

20000 

10000 

4000 

2000 

1000 

4 00 

200 

doo 

■4 
20 

dO 



PS. APR =7 



PARTITION IS OUT OF MEMORY (1=YES) 
PARTITION CHECKPOINT IN PROGRESS (1=YES) 
PARTITION CHECKPOINT IS REQUESTED (1=YES) 
PARTITION IS NOT CHECKPOINTABLE (1=YES) 
PARTITION IS FIXED (1=YES) 
PARITY ERROR IN PARTITION (1=YES) 
MARKED BY SHUFFLER FOR LONG I/O (1=YES) 
PARTITION IS NOT SHUFFLEABLE (1=YES) 
LIBRARY OR COMMON BLOCK (1=YES) 

POSITION INDEPENDENT LIBRARY OR COMMON (1=YES) 
SYSTEM CONTROLLED PARTITION (1=YES) 
DRIVER IS LOADED IN PARTITION (1=YES) 
PARTITION SHOULD BE DELETED WHEN NOT ATTACHED 
(1=YES) 
STARTING APR NUMBER MASK 



ATTACHMENT DESCRIPTOR OFFSETS 



, ASECT 





.=0 






000000 


A.PCBL: 


.BLKW 


1 


000002 


A. PR I: 


.BLKB 


1 


000003 


A. IOC: 


.BLKB 


1 


000004 


A.TCB: 


.BLKW 


1 


000006 


A.TCBL: 


.BLKW 


1 


000010 


A.STAT: 


• BLKB 


1 


000011 


A.MPCT: 


.BLKB 


1 


000012 


A.PCB: 


.BLKW 


1 


000014 


A.LGTH= 







PCB ATTACHMENT QUEUE THREAD WORD 

PRIORITY OF ATTACHED TASK 

I/O COUNT THROUGH THIS DESCRIPTOR 

TCB ADDRESS OF ATTACHED TASK 

TCB ATTACHMENT QUEUE THREAD WORD 

STATUS BYTE 

MAPPING COUNT OF TASK THRU THIS DESCRIPTOR 

PCB ADDRESS OF ATTACHED TASK 

;LENGTH OF ATTACHMENT DESCRIPTOR 



ATTACHMENT DESCRIPTOR STATUS BYTE BIT DEFINITIONS 



.PSECT 
AS.DEL=10 
AS. EXT =4 
AS.WRT=2 
AS.RED=1 



TASK HAS DELETE ACCESS (1=YES) 
TASK HAS EXTEND ACCESS (1=YES) 
TASK HAS WRITE ACCESS (1=YES) 
TASK HAS READ ACCESS (1=YES) 



, ENDC ;SYSDEF 
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PKTDF$ 



PKTDF$ 





.ASECT 






.=177774 




177774 


A.KSR5: .BLKW 


1 


177776 


A.DQSR: .BLKW 


1 


000000 


.BLKW 


1 


000002 


A.CBL: .BLKW 


1 



ASYNCHRONOUS SYSTEM TRAP CONTROL BLOCK OFFSET DEFINITIONS 

SOME POSITIONAL DEPENDENCIES BETWEEN THE OCB AND THE AST CONTROL 
BLOCK ARE RELIED UPON IN THE ROUTINE $FINXT IN THE MODULE SYSXT. 



SUBROUTINE KISAR5 BIAS (A.CBL=0) 

DEQUEUE SUBROUTINE ADDRESS (A.CBL=0) 

AST QUEUE THREAD WORD 

LENGTH OF CONTROL BLOCK IN BYTES 

IF A.CBL = 0, THE AST CONTROL BLOCK IS 

TO BE DEALLOCATED BY THE DEQUEUE SUBROUTINE 

POINTED TO BY A.DQSR MAPPED VIA APR 5 

VALUE A.KSR5. THIS IS CURRENTLY USED ONLY 

BY THE FULL DUPLEX TERMINAL DRIVER FOR 

UNSOLICITED CHARACTER ASTS. 

IF THE LOW BYTE OF A.CBL = 0, AND THE 

HIGH BYTE IS NOT = 0, THE AST CONTROL BLOCK 

IS A SPECIFIABLE AST, WITH LENGTH, C.LGTH. 

IF THE HIGH BYTE OF A.CBL = AND THE LOW 

BYTE > 0, THEN THE LOW BYTE IS THE LENGTH 

OF THE AST CONTROL BLOCK. IF THE HIGH BYTE 

OF A.CBL = AND THE LOW BYTE IS NEGATIVE, 

THIS IS A KERNEL AST. SEE BELOW FOR 

A DESCRIPTION OF A.CBL FOR KERNEL ASTS. 

NUMBER OF BYTES TO ALLOCATE ON TASK STACK 

AST TRAP ADDRESS 

NUMBER OF AST PARAMETERS 

FIRST AST PARAMETER 



000004 


A. BYT: 


• BLKW 


1 


000006 


A. AST: 


.BLKW 


1 


000010 


A.NPR: 


.BLKW 


1 


000012 


A.PRM: 


.BLKW 


1 



THE SPECIFIABLE AST CODES MUST NOT BE 0. 



AS.FPA=1 
AS.RCA=2 
AS.RRA=3 
AS.PFA=4 
AS.REA=5 
AS.CAA=6 



CODE FOR FLOATING POINT AST 

CODE FOR RECEIVE DATA AST 

CODE FOR RECEIVE BY REFERENCE AST 

CODE FOR POWERFAIL AST 

CODE FOR REQUESTED EXIT (ABORT) AST 

CODE FOR COMMAND ARRIVAL AST FOR CLIS 



ABORTER SUBCODES FOR ABORT AST (AS.REA) TO BE RETURNED ON USER'S 
STACK 



AB.NPV=1 
AB.TYP=2 



ABORTER IS NONPRIVILEGED (1=YES) 
ABORT FROM DIRECTIVE (0=YES) 
ABORT FROM CLI COMMAND (1=YES) 
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KERNEL AST CONTROL BLOCK DEFINITIONS 

THE LOW BYTE OF A.CBL FOR A KERNEL AST HAS THE FOLLOWING FORMAT: 

BIT #2 00 ALWAYS EQUALS 1 

BIT #100 IS ZERO IF $SGFIN MUST BE CALLED DURING AST PROCESSING 

THE REMAINING SIX BITS ARE USED AS THE KERNEL AST TYPE FIELD 

BECAUSE THERE ARE ONLY 6 BITS AVAILABLE TO THE KERNEL AST 
INDEX FIELD, ONLY (2**6) -1 KERNEL AST TYPES ARE POSSIBLE. 



AK.BUF=200 
AK.OCB=201 
AK.GBI=202 
AK.TBT=203 
AK.DIO=204 



BUFFERED I/O COMPLETION AST 
OFFSPRING EXIT 
GENERAL BUFFERED I/O AST 
TASK FORCED T-BIT TRAP AST 
DELAYED I/O (M-PLUS COMPATIBLE) 



OFFSPRING CONTROL BLOCK DEFINITIONS 

SOME POSITIONAL DEPENDENCIES EXIST BETWEEN THE OCB AND THE AST 
CONTROL BLOCK IN ROUTINE $FINXT IN MODULE SYSXT 



OCB LINK WORD 

ADDRESS OF MCR COMMAND LINE 

PARENT TCB ADDRESS 

EXIT AST ADDRESS 

EXIT EVENT FLAG 

EXIT STATUS BLOCK VIRTUAL ADDRESS 

EXIT STATUS BUFFER 

; LENGTH OF OCB 





.=0 






000000 


O.LNK: 


.BLKW 


1 


000002 


O.MCRL: 


.BLKW 


1 


000004 


O.PTCB: 


.BLKW 


1 


000006 


O.AST: 


.BLKW 


1 


000010 


O.EFN: 


.BLKW 


1 


000012 


O.ESB: 


.BLKW 


1 


000014 


O.STAT: 


.BLKW 


8 


000034 


O.LGTH= 







I/O PACKET OFFSET DEFINITIONS 



.ASECT 





.=0 






000000 


I.LNK 


• BLKW 


1 


000002 


I.PRI 


.BLKB 


1 


000003 


I.EFN 


.BLKB 


1 


000004 


I. TCB 


.BLKW 


1 


000006 


I.LN2 


.BLKW 


1 


000010 


I.UCB 


.BLKW 


1 


000012 


I.FCN 


.BLKW 


1 ; 


000014 


I. IOSE 


5: .BLKW 


1 ; 


000016 




.BLKW 


1 


000020 




.BLKW 


1 


000022 


LAST 


.BLKW 


1 


000024 


I. PRM 


.BLKW 


1 


000026 




.BLKW 


6 ; 


000042 




.BLKW 


1 


000044 


I. ATT 


L=. 




000044 


I.LGT 


H = . 





I/O QUEUE THREAD WORD 

REQUEST PRIORITY 

EVENT FLAG NUMBER 

TCB ADDRESS OF REQUESTOR 

POINTER TO SECOND LUN WORD 

POINTER TO UNIT CONTROL BLOCK 

I/O FUNCTION CODE 

VIRTUAL ADDRESS OF I/O STATUS BLOCK 

I/O STATUS BLOCK RELOCATON BIAS 

I/O STATUS BLOCK ADDRESS 

AST SERVICE ROUTINE ADDRESS 

RESERVED FOR MAPPING PARAMETER #1 

PARAMETERS 1 TO 6 

USER MODE DIAGNOSTIC PARAMETER WORD 

MINIMUM LENGTH OF I/O PACKET (USED BY 
FILE SYSTEM TO CALCULATE MAXIMUM 
NUMBER OF ATTRIBUTES) 
LENGTH OF I/O REQUEST CONTROL BLOCK 
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; GROUP 


GLOBAL 


EV 


000000 
000002 
000003 
000004 
000006 


.'=0 

G.LNK: 

G.GRP: 

G.STAT: 

G . CNT : 

G.EFLG: 


.BLKW 
.BLKB 
.BLKB 
.BLKW 
.BLKW 


1 
1 
1 
1 
2 


000012 


G.LGTH=, 







;LINK WORD 
;GROUP NUMBER 
; STATUS BYTE 
;ACCESS COUNT 
; EVENT FLAGS 

;LENGTH OF GROUP GLOBAL CONTROL BLOCK 



STATUS BYTE DEFINITIONS 
GS.DEL=1 ;GROUP MARKED FOR DELETE 



; EXECUTIVE POOL MONITOR CONTROL FLAGS 



; SPOLST IS THE SYNCHRONIZATION WORD BETWEEN THE EXEC AND POOL MONITOR 



PC.HIH=1 

PC.LOW=2 

PC.ALF=4 

PC.NRM=PC.HIH*400 

PC.ALM=PC.LOW*400 



HIGH POOL LIMIT CROSSED (1=YES) 
LOW POOL LIMIT CROSSED (1=YES) 
POOL ALLOCATION FAILURE (1=YES) 
POOL TASK INHIBIT BIT FOR HIGH POOL 
POOL TASK INHIBIT BIT FOR LOW POOL 



$POLFL IS THE POOL USAGE CONTROL WORD 



PF.INS=40 
PF.LOG=100 
PF.REQ=200 
PF.ALL=1 77777 



REJECT NONPRIVtLEGED INS/RUN/REM 

LOGINS ARE DISABLED 

STALL REQUEST OF NONPRIV. TASKS 

TAKE ALL POSSIBLE ACTIONS TO SAVE POOL 





; CLI PARSER BLOC 


000000 


.'=0 

C . PTCB : 


.BLKW 1 


000002 


C . PNAM : 


.BLKW 2 


000006 


C.PSTS: 


.BLKW 1 


000010 


C.PDPL: 


.BLKB 1 


000011 


C.PCPL: 


.BLKB 1 


000012 


C.PRMT: 





ADDRESS OF CLI 'S TCB 

CLI NAME 

STATUS MASK 

LENGTH OF DEFAULT PROMPT 

LENGTH OF CNTRL/C PROMPT 

START OF ASCII PROMPT STRINGS 

THE DEFAULT STRING IS CONCANTENATED 

WITH THE ~C STRING 
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STATUS BIT DEFINITIONS 



CP.NUL=1 

CP.MSG=2 

CP.LGO=4 

CP.DSB=10 

CP.PRV=20 

CP.SGL=4 

CP.NIO=100 

CP.RST=200 

CP. EXT =400 



PASS EMPTY COMMAND LINES TO CLI 

CLI DESIRES SYSTEM MESSAGES 

CLI WANTS COMMANDS FROM LOGGED OFF TTYS 

CLI IS DISABLED 

USER MUST BE PRIV TO SET TTY TO THIS CLI 

DON'T HANDLE CONTINUATIONS (M-PLUS ONLY) 

MCR. .., HEL, BYE DO NO I/O TO TTY 

HEL, BYE ALSO DO NOT SET CLI ETC. 

ABILITY TO SET TO THIS CLI IS RESTRICTED 

TO THE CLI ITSELF 

PASS TASK EXIT PROMPT REQUESTS TO CLI 



IDENTIFIER CODES FOR SYSTEM TO CLI MESSAGES. 



CODES - 
CODES 12? 



CM.INE=1 

CM.IND=2 

CM.CEN=3 

CM. CDS =4 

CM.ELM=5 

CM. EXT =6 

CM.LKT=7 

CM.RMT=8. 

CM.MSG=9. 



127. ARE RESERVED FOR USE BY DIGITAL, 
- 255. ARE RESERVED FOR USE BY CUSTOMERS 



CLI INITIALIZED ENABLED 

CLI INITIALIZED DISABLED 

CLI ENABLED 

CLI DISABLED 

CLI BEING ELIMINATED 

CLI MUST EXIT IMMEDIATELY 

NEW TERMINAL LINKED TO CLI 

TERMINAL REMOVED FROM CLI 

GENERAL MESSAGE TO CLI 



000000 
000002 
000004 
000006 
000007 
000010 
000012 
000013 



ANCILLARY CONTROL BLOCK (ACB) DEFINITIONS 



.=0 

A.REL: 
A.DIS: 
A.MAS: 

A.NUM: 

A.LIN: 
A.ACC: 
A.STA: 



.BLKW 
.BLKW 
.BLKW 
.BLKB 
.BLKB 
.BLKW 
.BLKB 
.BLKB 



000014 A.LEN1 = 



ACD RELOCATION BIAS 

ACD DISPATCH TABLE POINTER 

ACD FUNCTION MASK 

ACD IDENTIFICATION NUMBER 

RESERVED 

ACD LINK WORD 

ACD ACCESS COUNT 

ACD STATUS BYTE 

LENGTH OF PROTOTYPE ACB 





,=A.LIN 




000010 


A.IMAP 


.BLKW 


1 


000012 


A.IBUF 


.BLKW 


1 


000014 


A.ILEN 


.BLKW 


1 


000016 


A.SMAP 


.BLKW 


1 


000020 


A.SBUF 


: .BLKW 


1 


000022 


A.SLEN 


: .BLKW 


1 


000024 


A.IOS: 


.BLKW 


2 


000030 


A. RES: 


.BLKW 


1 



000032 A.LEN2=. 



FULL ACB OVERLAPS PROTOTYPE ACB 

ACD INTERRUPT BUFFER RELOCATION BIAS 

ACD INTERRUPT BUFFER ADDRESS 

ACD INTERRUPT BUFFER LENGTH 

ACD SYSTEM STATE BUFFER RELOCATION BIAS 

ACD SYSTEM STATE BUFFER ADDRESS 

ACD SYSTEM STATE BUFFER LENGTH 

ACD I/O STATUS 

RESERVED FOR USE BY THE ACD 

/LENGTH OF FULL ACB 
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DEFINE THE FLAG VALUES IN THE OFFSET U.AFLG 



UA.ACC=1 

UA.PR0=2 

UA.ECH=4 

UA.TYP=10 

UA.SPE=2 

UA.PUT=4 

UA.CAL=100 

UA.COM=200 

UA.ALL=4 00 

UA.TRA=1000 



ACCEPT THIS CHARACTER 

PROCESS THIS CHARACTER 

ECHO THIS CHARACTER 

FORCE THIS CHARACTER INTO TYPEAHEAD 

THIS CHARACTER HAS A SPECIAL ECHO 

PUT THIS CHARACTER IN THE INPUT BUFFER 

CALL THE ACD BACK AFTER THE TRANSFER 

COMPLETE THE INPUT REQUEST 

ALLOW PROCESSING OF THIS I/O REQUEST 

TRANSFER CHARS. WHEN I/O COMPLETES 



000000 
000002 
000004 
000006 
000010 
000012 
000014 
000016 
000020 
000022 



DEFINE THE ACD ENTRY POINTS (OFFSETS INTO THE DISPATCH TABLE) 



.=0 

A.ACCE 
DEQU 
POWE 
INPU 
OUTP 
A. CONN 
A. DISC 
A.RECE 
A. PROC 
A. CALL 



.BLKW 
.BLKW 
.BLKW 
.BLKW 

• BLKW 

• BLKW 
.BLKW 
.BLKW 
.BLKW 
.BLKW 



I/O REQUEST ACCEPTANCE ENTRY POINT 

I/O REQUEST DEQUEUE ENTRY POINT 

POWER FAILURE ENTRY POINT 

INPUT COMPLETION ENTRY POINT 

OUTPUT COMPLETION ENTRY POINT 

CONNECTION ENTRY POINT 

DISCONNECTION ENTRY POINT 

INPUT CHARACTER RECEPTION ENTRY POINT 

INPUT CHARACTER PROCESSING ENTRY POINT 

CALL ACD BACK AFTER TRANSFER ENTRY POINT 



DEFINE THE STATUS BITS IN A.STA OF THE PROTOTYPE ACB 



AS.DEL=1 
AS.DIS=2 



;ACD IS MARKED FOR DELETE 
,-ACD IS DISABLED 



.PSECT 
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SCBDF$ , ,SYSDEF 



SCBDF$ 



STATUS CONTROL BLOCK 

THE STATUS CONTROL BLOCK (SCB) DEFINES THE STATUS OF A DEVICE 
CONTROLLER. THERE IS ONE SCB FOR EACH CONTROLLER IN A SYSTEM. 
THE SCB IS POINTED TO BY UNIT CONTROL BLOCKS. TO EXPAND ON THE 
TELETYPE EXAMPLE ABOVE, EACH TELETYPE INTERFACED VIA A DL11-A 
WOULD HAVE A SCB SINCE EACH DL11-A IS AN INDEPENDENT INTERFACE 
UNIT. THE TELETYPES INTERFACED VIA THE DHii WOULD ALSO EACH HAVE 
AN SCB SINCE THE DH11 IS A SINGLE CONTROLLER BUT MULTIPLEXES MANY 
UNITS IN PARALLEL. 



.ASECT 





.=177772 




177772 


S.RCNT 


': .BLKB 


1 


177773 


S.ROFI 


-i .BLKB 


1 


177774 


S.BMST 


/: .BLKW 


1 


177776 


S.BMSF 


(: .BLKW 


1 


000000 


S.LHD: 


.BLKW 


2 


000004 


S.PRI 


.BLKB 


1 


000005 


S.VCT 


.BLKB 


1 


000006 


S.CTM 


• .BLKB 


1 


000007 


S.ITM 


• .BLKB 


1 


000010 


S.CON 


.BLKB 


1 


000011 


S.STS 


.BLKB 


1 


000012 


S.CSR 


.BLKW 


1 


000014 


S.PKT 


.BLKW 


1 


000016 


S.FRK 


.BLKW 


1 


000020 


S.DMC£ 


3: 




000020 




• BLKW 


1 


000022 




.BLKW 


1 


000024 




.BLKW 


1 



NUMBER OF REGISTERS TO COPY ON ERROR 

OFFSET TO FIRST DEVICE REGISTER 

SAVED I/O ACTIVE BITMAP AND POINTER TO EMB 

DEVICE I/O ACTIVE BIT MASK 

CONTROLLER I/O QUEUE LISTHEAD 

DEVICE PRIORITY 

INTERRUPT VECTOR ADDRESS /4 

CURRENT TIMEOUT COUNT 

INITIAL TIMEOUT COUNT 

CONTROLLER INDEX 

CONTROLLER STATUS (0=IDLE, 1=BUSY) 

ADDRESS OF CONTROL STATUS REGISTER 

ADDRESS OF CURRENT I/O PACKET 

FORK BLOCK LINK WORD 

DM11-BB CSR FOR FDX TTDRV 

FORK-PC 

FORK-R5 

FORK-R4 



.IF NB SYSDEF 

.IF DF L$$DRV & M$$MGE 

.BLKW 1 ; FORK-DRIVER RELOCATION BASE 

.ENDC ;L$$DRV & M$$MGE 



S.CCB: 






S.MPR: 


• BLKW 


6 




.BLKW 


1 


S.UMHD: 


• BLKW 


2 


S.UMCT: 


.BLKW 


1 



MIXED MASSBUS CHANNEL CONTROL BLOCK 

11/70 EXTENDED MEMORY UNIBUS DEVICE C-BLOCK 

BUFFER WORD 

LIST HEAD FOR UMR ASSIGNMENT BLOCK (S) 

COUNT OF AVAILABLE UMR ASSIGNMENT BLOCK (S) 



.IFF 



, PSECT 
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STATUS CONTROL BLOCK PRIORITY BYTE CONDITION CODE STATUS BIT 
DEFINITIONS 



SP.EIP=1 
SP.ENB=2 
SP.LOG=4 
SPARE=10 



ERROR IN PROGRESS (1=YES) 
ERROR LOGGING ENABLED (0=YES) 
ERROR LOGGING AVAILABLE (1=YES) 
SPARE BIT 



000010 
000011 



MAPPING ASSIGNMENT BLOCK (FOR UNIBUS MAPPING REGISTER ASSIGNMENT) 



.=0 
000000 M.LNK: 
000002 M.UMRA 
000004 M.UMRN 
000006 M.UMVL 



M.UMVH 
M.BFVH 



000012 M.BFVL: .BLKW 



.ASECT 

.BLKW 
.BLKW 
.BLKW 
.BLKW 
.BLKB 
.BLKB 



000014 M.LGTH=. 



;LINK WORD 

;ADDRESS OF FIRST ASSIGNED UMR 

;NUMBER OF UMR'S ASSIGNED * 4 

;LOW 16 BITS MAPPED BY 1ST ASSIGNED UMR 

;HIGH 2 BITS MAPPED IN BITS 4 AND 5 

;HIGH 6 BITS OF PHYSICAL BUFFER ADDRESS 

;LOW 16 BITS OF PHYSICAL BUFFER ADDRESS 

;LENGTH OF MAPPING ASSIGNMENT BLOCK 



.ENDC ;SYSDEF 



.PSECT 



C-3J 



SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 



TCBDF$ 



TCBDF$ , ,SYSDEF 



TASK CONTROL BLOCK OFFSET AND STATUS DEFINITIONS 
TASK CONTROL BLOCK 



000002 

000003 

000004 

000006 

000012 

000016 

000022 

000026 

000030 

000032 

000034 

000036 

000040 

000041 

000044 

000046 

000050 

000052 

000054 

000056 

000057 

000060 



T. 

T. 
T, 
T. 
T. 



.=0 

T.LNK: 
T.PRI: 
T.IOC: 
.CPCB: 
.NAM: 
.RCVL: 
,ASTL: 
.EFLG: 
T.UCB: 
T.TCBL: 
T.STAT: 
T.ST2: 
T.ST3: 
T.DPRI: 
T.LBN: 
T.LDV: 
T.PCB: 
T.MXSZ: 
T.ACTL: 
T . SAST : 

T.TIO: 
T.TKSZ: 



.ASECT 

.BLKW 

.BLKB 

.BLKB 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKB 

.BLKB 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKW 

.BLKB 

.BLKB 

.BLKW 



1 

1 

1 

1 

2 

2 

2 

2 

1 
1 
1 
1 
1 
1 
3 
1 
1 
1 
1 
1 
1 
1 
1 



UTILITY LINK WORD 

TASK PRIORITY 

I/O PENDING COUNT 

POINTER TO CHECKPOINT PCB 

TASK NAME IN RAD 50 

RECEIVE QUEUE LISTHEAD 

AST QUEUE LISTHEAD 

TASK LOCAL EVENT FLAGS 1-32 

UCB ADDRESS FOR PSEUDO DEVICE ■TI' 

TASK LIST THREAD WORD 

FIRST STATUS WORD (BLOCKING BITS) 

SECOND STATUS WORD (STATE BITS) 

THIRD STATUS WORD (ATTRIBUTE BITS) 

TASK'S DEFAULT PRIORITY 

LBN OF TASK LOAD IMAGE 

UCB ADDRESS OF LOAD DEVICE 

PCB ADDRESS OF TASK PARTITION 

MAXIMUM SIZE OF TASK IMAGE (MAPPED ONLY] 

ADDRESS OF NEXT TASK IN ACTIVE LIST 

SPECIFIED AST LISTHEAD 

UNUSED BYTE 

BUFFERED I/O COUNT 

TASK SIZE (FROM L$BLDZ IN LABEL BLK) IN: 

UNMAPPED SYSTEMS - BYTES 

MAPPED SYSTEMS - 32 WORD BLOCKS 
TASK SIZE (FROM L$BMXZ IN LABEL BLK) 
FOR RSX11S SYSTEMS ONLY 

MAPPED SYSTEMS - 32 WORD BLOCKS 

UNMAPPED SYSTEMS - BYTES 



$$$ = . 

T.ATT: 

T.OFF: 



.=$$$ 



.BLKW 

.BLKW 





.BLKB 


1 


T.SRCT: 


.BLKB 


1 


T.RRFL: 


.BLKW 


2 



. IF NDF P$$LAS 
.ENDC ;P$$LAS 



MARK START OF PLAS AREA 

ATTACHMENT DESCRIPTOR LISTHEAD 

OFFSET TO TASK IMAGE IN PARTITION 

IF A$$HDR IS DEFINED, THIS WORD ALSO 

INCLUDES THE LENGTH OF THE ALTERNATE 

HEADER REFRESH AREA STORED IN T.HDLN 

RESERVED 

SREF WITH EFN COUNT IN ALL RECEIVE QUEUES 

RECEIVE BY REFERENCE LISTHEAD 



; POINT TO START OF PLAS AREA 
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$$$ = . 
T. OCBH: 
T.RDCT: 



.=$$$ 



IF NB SYSDEF 



.BLKW 2 
,BLKW 1 

.IF NDF P$$OFF 

, ENDC ;P$$OFF 



;MARK START OF PARENT OFFSPRING TASKING AREA 
;OFFSPRING CONTROL BLOCK LISTHEAD 
OUTSTANDING OFFSPRING COUNT 



; POINT TO START OF PARENT OFFSPRING AREA 



$$$ = . 

T.EFLM: 



,=$$$ 



.BLKW 



MARK START OF EVENT FLAG MASK AREA 
EVENT FLAG MASK WORD 
EVENT FLAG MASK ADDRESS 



.IF NDF S$$TOP & T$$BUF 

; POINT TO START OF EVENT FLAG MASK AREA 
.ENDC ;S$$TOP & T$$BUF 



$$$ = . 
T.HDLN: 



=$$$ 



BLKB 1 ;TASK HEADER LENGTH IN 32-WORD BLOCKS 

, IF NDF A$$HDR 



.ENDC ;A$$HDR 



;NOT SUPPORTED IF NDF 



$$$ = . 
T.GGF: 



,=$$$ 



•BLKB 1 ;GROUP GLOBAL USE COUNT FOR TASK 

, IF NDF G$$EFN ! R$$SND 
, ENDC ;G$$EFN ! R$$SND 



T.LGTH=. 
T.EXT=0 



, EVEN 



IFF 



; LENGTH OF TASK CONTROL BLOCK 
; LENGTH OF TCB EXTENSION 



TASK STATUS DEFINITIONS 

FIRST STATUS WORD (BLOCKING BITS) 



TS.EXE= 
TS.RDN= 
TS.MSG= 
TS,NRP= 
TS.RUN = 
TS.HLD= 
TS.STP= 
TS.OUT= 
TS.CKP^ 
TS.CKR= 



aooooo 

'40000 
20000 
1 0000 
4000 
2 000 
1000 
4 00 
200 
100 



TASK NOT IN EXECUTION (1=YES) 

I/O RUN DOWN IN PROGRESS (1=YES) 

ABORT MESSAGE BEING OUTPUT (1=YES) 

TASK MAPPED TO NONRESIDENT PARTITION (1=YES) 

TASK IS RUNNING ON ANOTHER PROCESSOR (1=YES) 

TASK HALF-LOADED BY TASK LOADER 

TASK EXTERNALLY BLOCKED VIA CLI COMMAND 

TASK IS OUT OF MEMORY (1=YES) 

TASK IS BEING CHECKPOINTED (1=YES) 

TASK CHECKPOINT REQUESTED (1=YES) 
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TASK BLOCKING STATUS MASK 
TS.BLK=TS.CKP!TS.CKR!TS.EXE!TS.MSG!TS.NRP!TS.OUT!TS.RDN!TS.STP 



SECOND STATUS WORD (STATE BITS) 



T2.AST= 
T2.DST= 
T2.CHK= 
T2.CKD= 
T2.SEF= 

T - ? HYT1; 

T2.REX= 
T2.CAF= 
T2.HLT= 
T2.AB0= 
T2.STP= 
T2.STP= 
T2.SPN = 
T2.SPN = 
T2.WFR= 
T2.WFR= 



100000 

40000 

20000 

10000 

4000 

2000 

1000 

400 

200 

100 

40 

20 

d0 

4 

■2 

a 



AST IN PROGRESS (1=YES) 

AST RECOGNITION DISABLED (1=YES) 

TASK NOT CHECKPOINTABLE (1=YES) 

CHECKPOINTING DISABLED (1=YES) 

TASK STOPPED FOR EVENT FLAGS (1=YES) 

TASK FIXED IN MEMORY (1=YES) 

ABORT AST EFFECTED OR IN PROGRESS (1=YES) 

DYN CHECKPOINT SPACE ALLOCATION FAILURE 

TASK IS BEING HALTED (1=YES) 

TASK MARKED FOR ABORT (1=YES) 

SAVED T2.STP ON AST IN PROGRESS 

TASK STOPPED (1=YES) 

SAVED T2.SPN ON AST IN PROGRESS 

TASK SUSPENDED (1=YES) 

SAVED T2.WFR ON AST IN PROGRESS 

TASK IN WAITFOR STATE (1=YES) 



THIRD STATUS WORD (ATTRIBUTE BITS) 



T3.ACP= 
T3.PMD= 
T3.REM = 
T3.PRV= 
T3.MCR= 
T3.SLV= 
T3.CLI = 
T3.RST= 
T3.NSD= 
T3.CAL= 
T3.ROV= 
T3.NET= 
T3.GFL= 

T3.SWS= 



100000 

40000 

20000 

10000 

4000 

2000 

1000 

400 

200 

100 

40 

20 

10 

4 

2 

1 

.ENDC ;SYSDEF 

.PSECT 



ANCILLARY CONTROL PROCESSOR (1=YES) 

DUMP TASK ON SYNCHRONOUS ABORT (0=YES) 

REMOVE TASK ON EXIT (1=YES) 

TASK IS PRIVILEGED (1=YES) 

TASK REQUESTED AS EXTERNAL MCR FUNCTION (1=YES) 

TASK IS A SLAVE TASK (1=YES) 

TASK IS A COMMAND LINE INTERPRETER (1=YES) 

TASK IS RESTRICTED (1=YES) 

TASK DOES NOT ALLOW SEND DATA 

TASK HAS CHECKPOINT SPACE IN TASK IMAGE 

TASK HAS RESIDENT OVERLAYS 

NETWORK PROTOCOL LEVEL 

TASK HAS ITS GRP GBL EVENT FLAGS LOCKED 

RESERVED FOR FUTURE USE 

RESERVED FOR USE BY SOFTWARE SERVICES 

RESERVED FOR FUTURE USE 
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UCBDF$ 



UCBDF$ ,,TTDEF, SYSDEF 



UNIT CONTROL BLOCK 

THE UNIT CONTROL BLOCK (UCB) DEFINES THE STATUS OF AN INDIVIDUAL 
DEVICE UNIT AND IS THE CONTROL BLOCK THAT IS POINTED TO BY THE 
FIRST WORD OF AN ASSIGNED LUN. THERE IS ONE UCB FOR EACH DEVICE 
UNIT OF EACH DCB. THE UCB'S ASSOCIATED WITH A PARTICULAR DCB ARE 
CONTIGUOUS IN MEMORY AND ARE POINTED TO BY THE DCB. UCB'S ARE 
VARIABLE LENGTH BETWEEN DCB'S BUT ARE OF THE SAME LENGTH FOR A 
SPECIFIC DCB. TO FINISH THE TELETYPE EXAMPLE ABOVE, EACH UNIT ON 
BOTH INTERFACES WOULD HAVE A UCB. 

.ASECT 

.IF NB SYSDEF 







.IF DF 


E$$DVC 






.IF DF 


M$$MUP 




.=177766 








.IFF 






.=177770 








.ENDC 


;M$$MUP 




U.IOC: 


.BLKW 


2 




U.ERSI 


..: .BLKB 


1 




U. ERHI 


„: .BLKB 


1 




U. ERSC 


;: .BLKB 


1 




U. ERHC 


:: .BLKB 


1 






.ENDC 


;E$$DVC 






.ENDC 


; SYSDEF 




.=177' 


772 




177772 


U.MUP 






177772 


U.CLI 


.BLKW 


1 


177774 


U.LUIC 


:: .BLKW 


1 


177776 


U.OWN 


.BLKW 


1 


000000 


U.DCB 


: .BLKW 


1 


000002 


U.RED 


.BLKW 


1 


000004 


U.CTL 


.BLKB 


1 


000005 


U.STS 


: .BLKB 


1 


000006 


U.UNI' 


[": .BLKB 


1 


000007 


U.ST2 


: .BLKB 


1 


000010 


U.CW1 


: .BLKW 


1 


000012 


U.CW2 


: .BLKW 


1 


000014 


U.CW3 


: .BLKW 


1 


000016 


U.CW4 


: .BLKW 


1 


000020 


U.SCB 


: .BLKW 


1 


000022 


U.ATT 


: .BLKW 


1 


000024 


U.BUF 


: .BLKW 


1 


000026 




.BLKW 


1 


000030 


U.CNT 


: .BLKW 


1 



;IS U.OWN THERE? 



I/O COUNT SINCE MOUNT (ERROR LOG DEVS ONLY) 
SOFT ERROR LIMIT 
HARD ERROR LIMIT 
SOFT ERROR COUNT 
HARD ERROR COUNT 



MULTIUSER PROTECTION FLAG WORD 

TCB OF COMMAND LINE INTERPRETER 

LOGIN UIC - MULTI USER SYSTEMS ONLY 

OWNING TERMINAL - MULTI USER SYSTEMS ONLY 

BACK POINTER TO DCB 

POINTER TO REDIRECT UNIT UCB 

CONTROL PROCESSING FLAGS 

UNIT STATUS 

PHYSICAL UNIT NUMBER 

UNIT STATUS EXTENSION 

FIRST DEVICE CHARACTERISTICS WORD 

SECOND DEVICE CHARACTERISTICS WORD 

THIRD DEVICE CHARACTERISTICS WORD 

FOURTH DEVICE CHARACTERISTICS WORD 

POINTER TO SCB 

TCB ADDRESS OF ATTACHED TASK 

RELOCATION BIAS OF CURRENT I/O REQUEST 

BUFFER ADDRESS OF CURRENT I/O REQUEST 

BYTE COUNT OF CURRENT I/O REQUEST 
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000032 U.ACP=U.CNT+2 

000034 U.VCB=U.CNT+4 

000032 U.CBF=U.CNT+2 

000032 U.KCSR=U.CNT+2 

000034 U.KCS6=U.KCSR+2 



ADDRESS OF TCB OF MOUNTED ACP 
ADDRESS OF VOLUME CONTROL BLOCK 
CONTROL BUFFER RELOCATION AND ADDRESS 
CSR ADDRESS OF KMC-11 
CSR+6 OF KMC-11 



MAGTAPE DRIVER DEFINITIONS 



000036 U.SPC=U.CNT+6 

000036 U.SUB=U.CNT+6 

000040 U.FNUM=U.CNT+10 

000042 U.FCDE=U.CNT+12 



; SPACING COUNT 

;SUBCONTROLLER, PHYSICAL UNIT 
/FORMATTER NUMBER 
,-FUNCTION CODE AND INDEX 



MSCP DISK DRIVER UCB OFFSETS 



000036 U.UTMO=U.VCB+2 
000040 U.LHD=U.VCB+4 
000044 U.BPKT=U.VCB+10 



;UNIT COMMAND TIME OUT 

;UNIT OUTSTANDING I/O PACKET LISTHEAD 

;UNIT BAD BLOCK PACKET WAITING LIST 



CHARACTERISTICS OBTAINED FROM "GET UNIT STATUS" END PACKETS 



000050 U.MLUN=U.VCB+14 

000052 U.UNFL=U.VCB+16 

000054 U.HSTI=U.VCB+20 

000060 U.UNTI=U.VCB+24 

000070 U.MEDI=U.VCB+34 

000074 U.SHUN=U.VCB+40 

000076 U.SHST=U.VCB+42 

000100 U.TRCK=U.VCB+44 

000102 U.GRP=U.VCB+46 

000104 U.CYL=U.VCB+50 

000110 U.RCTS=U.VCB+54 

000112 U.RBNS=U.VCB+56 

000113 U.RCTC=U.VCB+57 



MULT I -UN IT CODE 
UNIT FLAGS 
HOST IDENTIFIER 
UNIT IDENTIFIER 
MEDIA IDENTIFIER 
SHADOW UNIT 
SHADOW UNIT STATUS 
UNIT TRACK SIZE 
UNIT GROUP SIZE 
UNIT CYLINDER SIZE 
UNIT RCT TABLE SIZE 
UNIT RBN "S / TRACK 
UNIT RCT COPIES 



CHARACTERISTICS OBTAINED FROM "ONLINE" OR "SET UNIT CHARACTERISTICS- 
END PACKETS 



000114 U.UNSZ=U.VCB+60 
000120 U.VSER=U.VCB+64 



;UNIT SIZE 

; VOLUME SERIAL NUMBER 



TERMINAL DRIVER DEFINITIONS 



.=U.BUF 

000024 U.TUX: .BLKW 1 

000026 U.TSTA: .BLKW 3 

000034 U.TTAB: .BLKW 1 



POINTER TO UCB EXTENSION (UCBX) 

STATUS TRIPLE-WORD 

IF 0: U.TTAB+1 IS S INGLE -CHARACTER TYPE-AHEAD 

BUFFER, CURRENTLY EMPTY 
IF ODD: U.TTAB+1 IS SINGLE -CHARACTER 
TYPE-AHEAD BUFFER AND HOLDS A 
CHARACTER 
IF NON-0 AND EVEN: POINTER TO MULTI-CHARACTER 
TYPE -AHEAD BUFFER 
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000036 


U.TLPP: 


.BLKB 


1 


000037 


U.TFRQ: 


.BLKB 


1 


000040 


U.TFLK: 


.BLKW 


1 


000042 


U.TCHP: 


.BLKB 


1 


000043 


U.TCVP: 


.BLKB 


1 


000044 


U.UIC: 


.BLKW 


1 


000046 


U.TTYP: 


.BLKB 


1 


000047 


U.TMTI: 


.BLKB 


1 


000050 


U.CTYP: 


.BLKW 


1 


000052 


U.ACB: 


.BLKW 


1 


000054 


U.AFLG: 


.BLKW 


1 


000056 


U.ADMA: 


.BLKW 


1 




• CONSOLE DRIVER 




!=U.CNT 






000030 


U.CTCB: 


.BLKW 


1 


000032 


U.COTQ: 


.BLKW 


2 


000036 


U.RED2: 


.BLKW 


1 



LINES PER PAGE 

FORK REQUEST BYTE 

FORK LIST LINK WORD 

CURRENT HORIZONTAL POSITION 

CURRENT VERTICAL POSITION 

TERMINAL UIC 

TERMINAL TYPE 

MODEM TIMER 

CONTROLLER TYPE 

ANCILLARY CONTROL DRIVER BLOCK ADDR 

ANCILLARY CONTROL DRIVER FLAGS WORD 

ANCILLARY CONTROL DRIVER DMA BUFFER 



ADDRESS OF CONSOLE LOGGER TCB 
I/O PACKET LIST QUEUE 
REDIRECT UCB ADDRESS 



DEFINE BITS IN STATUS WORD 1 (U.TSTA) 



S1.RST=1 

S1.RUB=2 

SI. ESC =4 

S1.RAL=10 

S1.RNE=20 

S1.CTO=4 

Sl.OBY=100 

S1.IBY=200 

S1.BEL=400 

S1.DPR=1000 

S1.DEC=2000 

S1.DSI=4000 

S1.CTS=10000 

S1.USI=20000 

Sl.OBF=40000 
S1.IBF=100000 



READ WITH SPECIAL TERMINATORS IN PROGRESS 

RUBOUT SEQUENCE IN PROGRESS (NON-SCOPE) 

ESCAPE SEQUENCE IN PROGRESS 

READ ALL IN PROGRESS 

ECHO SUPPRESSED 

OUTPUT STOPPED BY CTRL-0 

OUTPUT BUSY 

INPUT BUSY 

BELL PENDING 

DEFER PROCESSING OF CHAR. IN U.TECB 

DEFER ECHO OF CHAR. IN U.TECB 

INPUT PROCESSING DISABLED 

OUTPUT STOPPED BY CTRL-S 

UNSOLICITED INPUT IN PROGRESS 

BIT 14 RESERVED FOR NON-BUFFERED OUTPUT 

BUFFERED OUTPUT IN PROGRESS 

BUFFERED INPUT IN PROGRESS 



; DEFINE BITS IN STATUS WORD 2 (U.TSTA +2) 



S2.ACR=1 

S2.WRA=6 

S2.WRB=2 

S2.CR=10 

S2.BRQ=20 

S2.SRQ=4 

S2.ORQ=100 

S2.IRQ=200 

S2.HFL=3400 

S2. VFL=4000 

S2.HHT=10000 

S2.HFF=20000 

S2.FLF=40000 

S2.FDX=100000 



WRAP-AROUND (AUTOMATIC CR-LF) REQUIRED 
CONTEXT FOR WRAP-AROUND 
LOW BIT IN S2.WRA BIT PATTERN 
TRAILING CR REQUIRED ON OUTPUT 
BREAK-THROUGH -WRITE REQUEST IN QUEUE 
SPECIAL REQUEST IN QUEUE 
(IO. ATT, IO.DET, SF.SMC) 

OUTPUT REQUEST IN QUEUE (MUST = Sl.OBY) 
INPUT REQUEST IN QUEUE (MUST = Sl.IBY) 
HORIZONTAL FILL REQUIREMENT 
VERTICAL FILL REQUIREMENT 
HARDWARE HORIZONTAL TAB PRESENT 
HARDWARE FORM-FEED PRESENT 
FORCE LINE FEED BEFORE NEXT ECHO 
LINE IS IN FULL DUPLEX MODE 
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DEFINE BITS IN STATUS WORD 3 (U.TSTA+4) 



S3.RAL=10 

S3.RPO=20 

S3. WES =40 

S3.TAB=100 

S3.8BC=200 

S3.RCU=4 00 

S3.ABD=1000. 

S3.ABP=2000 

S3.WAL=4000 

S3.VER=10000 

S3.BCC=20000 

S3.DAO=40000 



S3.PCU=100000 



TERMINAL IS IN READ-PASS-ALL MODE 
(S3.RAL MUST = Sl.RAL) 
READ W/PROMPT OUTPUT IN PROGRESS 
TASK WANTS ESCAPE SEQUENCES 
TYPE-AHEAD BUFFER ALLOCATION REQUESTED 
PASS 8 BITS ON INPUT 
RESTORE CURSOR (MUST = TF.RCU*4O0) 
AUTO-BAUD SPEED DETECTION ENABLED 
AUTO-BAUD SPEED DETECTION IN PROGRESS 
WRITE -PASS -ALL (MUST = TF.WAL*400) 
LAST CHAR. IN TYPE-AHEAD BUFFER 
HAS PARITY ERROR 

LAST CHAR. IN TYPE -AHEAD BUFFER 
HAS FRAMING ERROR 
LAST CHAR. IN TYPE -AHEAD BUFFER 
HAS DATA OVERRUN ERROR 

NOTE - THE 3 BITS ABOVE MUST CORRESPOND 
TO THE RESPECTIVE ERROR FLAGS IN THE 
HARDWARE RECEIVE BUFFER 
POSITION CURSOR (MUST = TF.PCU*400) 



.PSECT 



DEVICE TABLE STATUS DEFINITIONS 

DEVICE CHARACTERISTICS WORD 1 (U.CW1) DEVICE TYPE DEFINITION BITS. 



DV. REC = 
DV.CCL: 
DV. TTY: 
DV. DIR: 

DV. SDI: 

DV. SQD; 
DV.MSD; 
DV. UMD: 
DV.MBO 
DV. EXT^ 
DV. SWL; 
DV. ISP; 

DV. OSP: 

DV. PSE; 
DV.COM: 

DV.F11: 

DV.MNT: 



= 1 

=2 

=4 

=10 

=20 

=4 

=100 

=200 

=4 00 

=400 

=1000 

=2000 

=4000 

=10000 

=20000 

=40000 

=100000 



RECORD ORIENTED DEVICE (1=YES) 

CARRIAGE CONTROL DEVICE (1=YES) 

TERMINAL DEVICE (1=YES) 

FILE STRUCTURED DEVICE (1=YES) 

SINGLE DIRECTORY DEVICE (1=YES) 

SEQUENTIAL DEVICE (1=YES) 

MASS STORAGE DEVICE (1=YES) 

USER MODE DIAGNOSTICS SUPPORTED (1=YES) 

DEVICE IS ON MASSBUS CONTROLLER (1=YES) 

DEVICE ON EXTENDED ADDRESSING CONTROLLER 

UNIT SOFTWARE WRITE LOCKED (1=YES) 

INPUT SPOOLED DEVICE (1=YES) 

OUTPUT SPOOLED DEVICE (1=YES) 

PSEUDO DEVICE (1=YES) 

DEVICE IS MOUNTABLE AS COM CHANNEL (1=YES) 

DEVICE IS MOUNTABLE AS Fll DEVICE (1=YES) 

DEVICE IS MOUNTABLE (1=YES) 



TERMINAL DEPENDENT CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 



U2.DH1 = 
U2.DJ1 = 
U2.RMT= 
U2.HFF= 
U2.L8S = 
U2.NEC= 

til r»r\m. 

u z. \-ni - 
U2.ESC: 
U2.LOG= 
U2.SLV 
U2.DZ1= 



=100000 

=40000 

=20000 

=10000 

=10000 

=4000 

=2000 

=1000 

=400 

=200 

=100 



UNIT IS A MULTIPLEXER (1=YES) 

UNIT IS A DJ11 (1=YES) 

UNIT IS REMOTE (1=YES) 

UNIT HANDLES HARDWARE FORM FEEDS (1=YES) 

OLD NAME FOR U2.HFF 

DON'T ECHO SOLICITED INPUT (1=YES) 

UNIT IS A CRT (1=YES) 

UNIT GENERATES ESCAPE SEQUENCES (1=YES) 

USER LOGGED ON TERMINAL (0=YES) 

UNIT IS A SLAVE TERMINAL (1=YES) 

UNIT IS A DZ11 (1=YES) 
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U2.HLD=40 

U2.AT.=20 

U2.PRV=10 

U2.L3S=4 

U2.SCS=4 

U2.VT5=2 

U2.LWC=1 



TERMINAL IS IN HOLD SCREEN MODE (1=YES) 

MCR COMMAND AT. BEING PROCESSED (1=YES) 

UNIT IS A PRIVILEGED TERMINAL (1=YES) 

UNIT IS A LA30S TERMINAL (1=YES) 

SCS-11 COMMAND TERMINAL (1=YES) 

UNIT IS A VT05B TERMINAL (1=YES) 

LOWER CASE TO UPPER CASE CONVERSION (0=YES) 



BIT DEFINITIONS FOR U.MUP (SYSTEMS WITH ALTERNATE CLI SUPPORT ONLY) 



UM.OVR=l 
UM.CLI=36 
UM.DSB=200 
UM.NBR=4 00 



OVERRIDE CLI INDICATOR 

CLI INDICATOR BITS 

TERMINAL DISABLED SINCE CLI ELIMINATED 

NO BROADCAST 



RH11-RS03/RS04 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 
U2.R04=100000 ;UNIT IS A RS04 (1=YES) 



RH11-TU16 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 
U2.7CH=10000 ;UNIT IS A 7 CHANNEL DRIVE (1-YES) 



TERMINAL DEPENDENT CHARACTERISTICS WORD 3 (U.CW3) BIT DEFINITIONS 
U3.UPC=20000 ;UPCASE OUTPUT FLAG 



UNIT CONTROL PROCESSING FLAG DEFINITIONS 



UC.ALG=200 

UC.NPR=100 

UC.QUE=40 

UC.PWF=20 

UC.ATT=10 

UC.KIL=4 

UC.LGH=3 



BYTE ALIGNMENT ALLOWED (l=NO) 
DEVICE IS AN NPR DEVICE (1=YES) 
CALL DRIVER BEFORE QUEUING (1=YES) 
CALL DRIVER AT POWERFAIL ALWAYS (1=YES) 
CALL DRIVER ON ATTACH/DETACH (1=YES) 
CALL DRIVER AT I/O KILL ALWAYS (1=YES) 
TRANSFER LENGTH MASK BITS 



UNIT STATUS BIT DEFINITIONS 



US.BSY=2 00 
US.MNT=100 
US.FOR=4 
US.MDM=20 
US.PWF=10 



;UNIT IS BUSY (i=YES) 

;UNIT IS MOUNTED (0=YES) 

;UNIT IS MOUNTED AS FOREIGN VOLUME (1=YES) 

;UNIT IS MARKED FOR DISMOUNT (1=YES) 

; POWERFAIL OCCURRED (1=YES) 



CARD READER DEPENDENT UNIT STATUS BIT DEFINITIONS 



US.ABO=l 
US.MDE=2 



;UNIT IS MARKED FOR ABORT IF NOT READY (1=YES) 
;UNIT IS IN 029 TRANSLATION NODE (1=YES) 
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FILES-11 DEPENDENT UNIT STATUS BITS 



US.WCK=10 

US.SPU=2 

US.W=1 



;WRITE CHECK ENABLED (1=YES) 
;UNIT IS SPINNING UP (1=YES) 
;VOLUME VALID IS SET (1=YES) 



KMC-11-LP DEPDENDENT UNIT STATUS BITS 
US.KPF=1 ;KMC-11 POWERFAIL INTERLOCK 



TERMINAL DEPENDENT UNIT STATUS BIT DEFINITIONS 



• IF NB TTDEF 



IF DF T$$CPW 



US . CRW=4 
US.DSB=2 
US.OIU=l 



, IFF ;T$$CPW 



US.DSB=10 
US.CRW=4 
US.ECH=2 
US. OUT =1 



.ENDC ;T$$CPW 
.ENDC ; TTDEF 



;UNIT IS WAITING FOR CARRIER (1=YES) 

;UNIT IS DISABLED (1=YES) 

;OUTPUT INTERRUPT IS UNEXPECTED ON UNIT (1=YES) 



UNIT IS DISABLED (1=YES) 

UNIT IS WAITING FOR CARRIER (1=YES) 

UNIT HAS ECHO IN PROGRESS (1=YES) 

UNIT IS EXPECTING OUTPUT INTERRUPT (1=YES) 



LPS11 DEPENDENT UNIT STATUS BIT DEFINITIONS 



US.FRK=2 
US.SHR=1 



;FORK IN PROGRESS (1=YES) 

; SHAREABLE FUNCTION IN PROGRESS (0=YES) 



MAGTAPE DEPENDANT UNIT STATUS BITS 



US.LAB=4 
US.BSP=2 



;UNIT HAS LABELED TAPE ON IT (1=YES) 
/INTERNAL BACKSPACE IN PROGRESS (1=YES) 



C-47 



SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 



UNIT STATUS EXTENSION (U.ST2) BIT DEFINITIONS 



US.0FL=1 
US.RED=2 
US.PUB=4 
US.UMD=10 



UNIT OFFLINE (1=YES) 

UNIT REDIRECTABLE (0=YES) 

UNIT IS PUBLIC DEVICE (1=YES) 

UNIT ATTACHED FOR DIAGNOSTICS (1=YES) 



MAG TAPE DENS SUPPORT IDENT IN CHAR WORD 3 (U.CW3) DEFENITION 
ASSIGNMENTS PER NUMERICAL SEQUENCE - 255. 



UD.UNS=0 
UD. 200=1 
UD. 556=2 
UD. 800=3 
UD. 160=4 
UD. 625=5 



UNSUPPORTED 


200BPI, 


7 


TRACK 


556BPI, 


7 


TRACK 


800BPI, 


7 


OR 9 TRACK 


1600BPI, 


9 


TRACK 


6250BPI, 


9 


TRACK 
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APPENDIX D 
USER-WRITTEN ANCILLARY CONTROL PROCESSORS 

This chapter is intended as a guide for the user in developing an 
Ancillary Control Processor (ACP) . It is not a tutorial and it is not 
a description of the logic of any DIGITAL-supplied ACP. You should be 
thoroughly familiar with the RSX-11M Guide to Writing an I/O Driver . 

This chapter provides the following information: 

• An overview of the RSX-11M I/O system 

• Descriptions of the types of ACPs 

• The attributes of an ACP 



• 



A description of the flow of an input/output request, 
emphasizing the role of the ACP 

System data structures used by the ACPs 

Examples of an ACP and an I/O driver 



D.l OVERVIEW OF THE RSX-11M I/O SYSTEM 

An Ancillary Control Processor (ACP) is one component of the RSX I/O 
system. The other major components are 

• File Control Services (FCS) or Record Management Services 
(RMS) 

• QIO$ directive processing in the Executive 

• Device drivers 

Figure D-l shows how an ACP fits into the overall structure. 

The philosophy and structure of the RSX-11M I/O system are described 
in detail in Chapter 2 of this manual. QIO$ directive processing is 
described in the RSX-11M/M-PLUS Executive Reference Manual. 
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User Task 



-I- 



FCS 



— — - Executive 



1 



ACP 



I 



I 



Device Driver 



Device 



ZK-227-81 



Figure D-l The RSX-11M I/O System 



D. 2 TYPES OF ANCILLARY CONTROL PROCESSORS 

An Ancillary Control processor (ACP) is a task that provides extended 
functions (complex operations requiring either multiple I/O requests 
or special privileged operations) for a class of I/O devices. 

ACPs may be divided into three types: 

• Those that manage file structures, such as F11ACP and MTAACP 

• Those that manage intertask or interprocessor communication, 
such as the network ACP (NETACP) 

• Those that perform special privileged operations on behalf of 
nonpr ivileged user tasks. 
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Some of the purposes of a user-written ACP are: 

• To implement a foreign file system 

• To extend the capabilities of a DIGITAL-supplied device driver 

• To extend the services of the operating system 

• To implement a communications protocol 

User-written ACPs extend functionality, not performance. If your 
application is performance-oriented, you should consider writing a 
special driver rather than an ACP. 



D.2. 1 ACPs Which Manage Files Structures 

DIGITAL supplies F11ACP for Files-11 disk structure and MTAACP for 
ANSI magnetic tapes. You may write an ACP to implement a foreign file 
system or tape format. Changes to the Executive, the I/O driver, or 
the data structures are not necessary if there are DIGITAL-supplied 
I/O operations that correspond to operations for the foreign format. 
The user-written ACP can use the built-in Executive Services (such as 
QIO$ directive processing) without change. 

Note that a user-written ACP is necessary only to support a file 
structure other than Files-11. To use the Files-11 structure with a 
foreign device, you need to write a device driver, and you may need to 
modify or extend disk initialization, management, or backup utilities. 



D.2.2 ACPs Which Manage Intertask or Interprocessor Communication 

DECnet/M and DECnet/M-PLUS both contain an example of an ACP that 
manages interprocessor communications: NETACP, used for management of 
the Digital Network Architecture Communications protocol. You may 
write an ACP to manage a foreign communications protocol. 



D.2. 3 ACPs Which Perform Privileged Operations for Unprivileged Tasks 

You may write an ACP to support extended capabilities for a class of 
devices (such as line printer spooling or associative name searching 
for data base devices) . This requires special support in the 
Executive I/O processing, in the I/O driver, and in the associated 
data structures. This type of ACP requires a user-written I/O driver 
that contains special code to support the ACP. 

An ACP may use the I/O driver interface to extend the services of the 
operating system (as in the case of a data base management system) , 
rather than to extend the services of an I/O device. 

RSX-11M contains no DIGITAL-supplied examples of the. types just 
described. Both RSX-11M and RSX-11M-PLUS, however, contain COT and 
CODRV, which are used to perform console logging. The COT task 
behaves in the fashion of an ACP, in that it receives I/O packets in 
its queue from user tasks. COT is not declared to the system as an 
ACP, though; it has no VCB or MOU interface. COT is enabled and 
disabled using MCR commands. 
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D.3 THE ATTRIBUTES OF AN ACP 

The classes of ACPs described above have the following attributes in 
common, which further define an ACP: 

• An ACP is an asynchronous privileged task. Refer to the 
RSX-11M/M-PLUS Task Builder Manual for a discussion of 
privileged task mapping and Executive access. 

• An ACP implements a protocol (or set of services) for a class 
of devices (for example, file-structured devices or sequential 
devices) . 

• An ACP functions as an extension of the Executive and 
frequently operates with Executive privilege. 

• An ACP can be enabled or disabled for a particular device. 

• An ACP is shareable among several device drivers and units. 



D. 3. 1 ACP as a Task 

An ACP is a task. It has all the attributes of a task, including: 

• A stack 

• A task name 

• Priority 

• Scheduling by the Executive 

An ACP, in contrast to a driver, operates as a task. While a driver 
handles interrupts, manipulates CSRs, and performs other 
device-specific operations, an ACP is not device bound and can take 
advantage of the services and control mechanisms available to tasks. 
ACPs can also use overlays, and can therefore be larger and have 
greater functionality than drivers. 

Because the ACP task is privileged, it has access to the Executive 
data structures and can use Executive facilities. 

Unlike other privileged tasks, an ACP has the capacity to receive I/O 
packets from other tasks by means of the QIO$ directive. This permits 
the ACP to act as an I/O handler, which can compete with user tasks 
for system resources more equitably than an I/O driver could. Also, 
unlike an I/O driver, an ACP can perform I/O to other devices during 
the processing of an I/O request. 



D.3. 2 Class of Devices 

An ACP can easily implement functions for a class of devices because 
it communicates via the QIO$ directive, which is relatively 
device-independent. (Drivers, in contrast, are written to suit the 
minute peculiarities of particular devices.) F11ACP, for example, 
implements the Files-11 structure for all types of disks and DECtapes. 
MTAACP implements ANSI magnetic tape format for all DIGITAL-supported 
9-track magnetic tape drives. 
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D.3.3 Extension of Executive 

An ACP extends the functionality of both the Executive and the device 
drivers in several ways: 

• By removing the burden of device managment (assigning space on 
a volume, locating the desired data area, and so on) from the 
programmer. 

• By handling the manipulation of device- and protocol-related 
data. 

• By permitting a device to be treated as a logical rather than 
a physical entity. 

• By allowing a device to be shared for simultaneous access. 
Each process that accesses a device is protected from other 
processes by the ACP and its protocol. The ACP also 
synchronizes access to the physical device. 



D.3.4 Enabling Capability and Disabling Capability 

An ACP can be enabled or disabled for a given device. When enabled, 
the device is available for use in the context of the protocol 
provided by the ACP. 



D.3.5 Shareability 

An ACP is shareable among several device drivers and units. 

D.4 THE FLOW OF AN I/O REQUEST 

This section describes the system interactions of an ACP during the 
flow of an I/O request. On the assumption that you have read Section 
2.6 of this manual, only those items relevant to ACPs are treated in 
detail. The structure of this section is similar to that of Section 
2.6. 

The I/O flow proceeds as described below: 

1. [Task issues a QIO$ directive] 

The Executive performs the following: 

a. First-level validity checks 

b. Redirect algorithm 

c. Additional validity checks 

2. [Executive obtains storage for and creates I/O packet] 

3. [Executive validates the function requested] 

If the function is an ACP function, the type of function 
validation depends on the type of ACP. 
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a. Standard DIGITAL-supplied ACP 

If the device is mounted with an ACP, the function 
code is validated to determine that it is an ACP 
function. The parameters are verified by code in the 
QIO processing module. The request is checked for 
proper order (for example, OPEN before CLOSE) and for 
valid buffers. The task that issues the I/O request 
must validate any additional parameter block required 
by the ACP. For some functions, an additional 
parameter buffer is allocated and filled in. 

Sometimes the I/O request can be transformed into a 
transfer function and queued to the proper driver. 
If the request cannot be queued to the driver or 
cannot be completed immediately, it is queued to the 
ACP. The request packet is inserted in the ACP's 
receive data queue and the ACP is unstopped or 
requested to run (depending on whether it was 
active) . 

b. Nonstandard ACPs and ACPs requiring special Executive 
or driver support 

The QIO$ directive processing cannot validate the ACP 
function request parameters. The I/O driver must do 
the validation. The UC.QUE bit in the driver must be 
set so that the QIO processing routine calls the 
driver directly, without queuing the I/O packet to 
the driver or to the ACP. 

The driver must perform the same functions for the 
ACP as the QIO processing code does for standard and 
replacement ACPs. 

4. [Driver processing] 

If the driver calls $GTPKT and the next request in the queue 
is an ACP function request, $GTPKT will queue the request to 
the ACP and activate the ACP. 

5. [ACP processing] 

Obtain Work 

As soon as the ACP is activated, it attempts to remove an I/O 
request packet from its receive data queue. To do this, the 
ACP switches to system state and calls $QRMVF to obtain the 
address of the I/O packet. (Note that the ACP does not use 
the RCVD$ directive to remove the packet from its receive 
queue.) When the ACP has obtained the address of the I/O 
packet, it returns to task state. 

Process I/O Request 

The ACP either completes the I/O request or translates it 
into a standard I/O driver request. The decision is based 
on: 

• Information in the data structures 

• Computation 

• Additional I/O 
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The ACP may do its own QIO requests to the driver; the ACP then 
calls $IOFIN with the I/O packet and the I/O status. 
Alternatively, when the I/O request is translated into a driver 
request, the ACP modifies the I/O packet to put it into the 
correct form for a driver request and passes it to the driver by 
calling $DRQRQ. if the I/O request has been completed, the ACP 
calls $IOFIN with the I/O packet and the I/O status. 

For example, MTAACP always deals with the driver through QIO 
requests, and finishes I/O itself by calling $IOFIN. 

The ACP then attempts to remove another request from its queue. 
If there are no more requests in the queue, the ACP stops itself 
by calling $STPCT. 



D.5 SYSTEM DATA STRUCTURES 

An ACP interfaces to the system through use of system data structures 
and through calls to Executive routines. This section describes 
ACP-specific information for the various data structures. Detailed 
information on the data structures and their interrelationships is 
contained in Section 2.7 and Chapter 4 of this manual. 

The following data structures comprise the complete set for I/O 
processing: 

• Task header 

• Window Block (WB) 

• File Control Block (FCB) 

• $DEVHD word, the Device Control Block (DCB) , and the Driver 
Dispatch Table (DDT) 

• Unit Control Block (UCB) 

• Status Control Block (SCB) 

• Volume Control Block (VCB) 

• I/O packet 

When you write an ACP, you are usually concerned only with the I/O 
packet, the DCB, the UCB, and the SCB. There are ACP-specific 
additions to and variations in the I/O packet, the DCB, and the UCB. 
The SCB is the same as that for an I/O driver. 



D.5. 1 The I/O Packet 

Figure D-2 shows the layout of the 18-word I/O packet, which is 
constructed by QIO$ directive processing. The fields in the I/O 
packet are described in detail in Section 4.1.1 of this manual. The 
following additions and variations exist for ACPs : 



I.FCN 



Contains the function code for the I/O request. The function 
code and modifier comprise a 16-bit field. Bits 13,14, and 15 
are reserved for ACP interface use. You must not assume that 
these bits are zero. 
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If the function code field is referenced, the value should be 
masked with 160000(8) for example: 



MOV I.FCN(R1),R0 
BIC #160000, R0 



; GET FUNCTION CODE FIELD 
; CLEAR OFF EXTRANEOUS BITS 



Although these bits are not currently in use, they should not be 
assumed to be zero in order to ensure future compatibility. If 
an I/O packet is requeued to the device driver, these bits must 
be cleared. 



I.PRM 



Contains the device-dependent parameters constructed from the 
last six words in the DPB. 

The following fields are defined for Files-11 nontransfer 
operations: 



.ASECT 
. =1 . PRM 
I.FIDP: 

I . RWAT : 



,BLKW 
.BLKW 



File ID address (Address double 

word format) 

Attribute block pointer (This field 

points to a buffer containing the 

attribute list and associated address 

doublewords) 

Extend control from parameter list 

Retrieval pointers desired 

Access control 

File name block pointer 

The following fields are defined for Files-11 transfer operations: 



I.EXTD: 


.BLKW 


2 


I.RTRV: 


.BLKB 


1 


I.ACTL: 


.BLKB 


1 


I.FNBP: 


.BLKW 


2 



.ASECT 






. =1 . PRM 






I.RWAD: 


.BLKW 


2 


I.RWCT: 


.BLKW 


1 




.BLKW 


1 


I.RWVB 


.BLKW 


1 




.BLKW 


1 


LLC KB: 


.BLKW 


1 



Transfer address doubleword 

Transfer count 

Unused 

Virtual block number 

Unused 

Address of lock block 

The above fields are set up by routines in the Executive. 

Only I.LCKB is referenced by $I0FIN; it must be either 
greater than 140000. 



or 
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I.LNK 


Link to next I/O packet 





I.EFN,I.PRI 


EFN 


PRI 


2 


I.TCB 


TCB address of requestor 


4 


I.LN2 


Address of second LUT word 


6 


I.UCB 


Address of redirect UCB 


10 


I.FCN 


Function code 


Modifier 


12 


I.IOSB 


Virtual address of I/O status block 


14 




Relocation bias of I/O status block 


16 




Real address of I/O status block 


20 


LAST 


Virtual address of AST service routine 


22 


I.PRM 




24 




Device 






parameters 























Figure D-2 I/O Packet 



D.5.2 The DCB 

The DCB is described in detail in Section 4.1.2 of this manual. The 
following additional information applies to ACPs: 

D.MSK 

In general, I/O requests marked as ACP functions are passed to 
the ACP; all others are passed to the device driver when it 
calls $GTPKT. 



D.5.3 The UCB 

The UCB is described in detail in Section 4.1.4 of this 
following additional information applies to ACPs: 



manual . 



The 



U.CTL 



UC.QUE - Queue bypass bit 



If UC.QUE is set, all I/O requests are passed to the 
driver without being queued first, regardless of any 
ACP-related processing in DRQIO. A driver that makes 
use of this option may alter the behavior of the file 
system, since some functions are normally passed 
directly to the ACP, bypassing the driver queue. 
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If UC.QUE and US. FOR are set, all DIGITAL-specif ic ACP 
processing is bypassed. In this case, the driver must 
do all address checking and relocation. 

The UC.QUE option allows user-written ACPs to validate 
the ACP function parameters. Each I/O driver supported 
by the user-written ACP must contain code to do the 
validation. The validation must be done at this point 
in the I/O processing, because the routines that do 
address checking and relocation assume that the memory 
management registers are in use by the tasks issuing the 
I/O. (Refer to the DRQIO module for examples of the 
techniques used to validate and save parameters.) 

UC.KIL - Unconditional cancel I/O call bit 

If UC.KIL is set, the I/O driver is called on a cancel 
I/O request even if the unit specified is not busy. 

Since ACP functions are dependent on sequencing, this 
function is normally turned into a no-op. 

An IO.KIL request has no effect on a mounted unit since 
the I/O queue is not flushed on the IO.KIL request when 
the DV.MNT (mountable) and US.MNT (mounted) bits are set 
for the unit. 



U.STS 



US . MNT 



US . FOR 



US . MDM 



If US.MNT is set, the unit is not mounted. US.MNT is 
cl'eared when the volume is mounted. 



If US. FOR is set, the volume is mounted as foreign. 
US. FOR is set when the volume is mounted. 



If US. MDM is set, the volume is marked for dismount. 

An ACP normally checks the US. MDM bit when it processes 
a new I/O request. The ACP refuses operations that 
create a channel for processing (such as OPEN) when 
US. MDM is set. After operations that terminate a 
channel (such as CLOSE) , the ACP checks the current 
count of active channels to see if all ACP-related 
processing has been completed. If it is, the ACP 
completes the dismount. 

US. MDM is set when the volume is to be dismounted. 



U.CW1 



This characteristics word is returned to the user task by the 
GLUN$ directive. U.CW1 is checked during validation of I/O 
request. The following bits are important to ACPs: 



DV.MNT 



If DV.MNT is set, the device is mountable. If a device 
is mountable, ACP functions can only be performed when 
it is mounted. 
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DV.COM 



DV. SQD 



DV. SDI 



DV.DIR 
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If DV.F11 is set, the device is a Files-11 device. 
DV.F11 is set for both disks and tapes. If the device 
is Files-11, the DV. SQD bit determines whether the 
device is random or sequential. 



If DV.COM is set, the device is mountable as a 
communications channel. This is used for DECnet. 



If DV. SQD is set, the device is sequential. If DV. SQD 
is reset, the device is random access. 



If DV. SDI is set, the device supports only a single 
directory. 



If DV.DIR is set, the device is a directory device. 



D.6 AN EXAMPLE OF AN ACP-I/0 DRIVER COMBINATION 

The following is an example of an ACP, including a special driver used 
by the ACP. This ACP, supplied for demonstration purposes only, 
•ounts the number of QIOs to a terminal. 

The modules supplied and their respective functions are: 

QDPRE.MAC - Prefix file for assembly 

QD DAT. MAC - Driver database 

QDDRV.MAC - Driver for ACP 

QDACP.MAC - The ACP itself 

QDCON.MAC - The task for enabling and disabling the ACP 

Example D-l An ACP-I/O Driver Combination 

.TITLE QDPRE 
.IDENT /01/ 

. ENABL LC 



This structure is purely for purposes of example. It is not intended to 
be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 
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**-QDPRE-QD: driver prefix file 

EXECUTIVE DEPENDENCIES 

The following is a list of the recognized Executive dependencies for the 
the QD: driver. If the implementation or functionality of the following 
features change, this driver and ACP may not function properly. 

1. The Executive I/O processing as described in RSX-11M Guide to Writing an I/O 
Driver remains unchanged. 

2. The following Executive routines remain unchanged: 

$SWSTK (SWSTK$) 
$BLXIO 
$EXRQP 
All of the routines documented in the RSX-11M Guide to Writing an I/O Driver 



System Macro Calls 



.MCALL UCBDF$ 
UCBDF$ 



QD driver-specific offsets 



, ASECT 



.=U.VCB+2 



End of UCB 



U.QACP 
U.QCTL 
U.QLUN 
U.QTRN 



:.BLKW 1 

:.BLKW 1 

:.BLKW 1 

r.BLKW 1 



UQ.STP==100000 
UQ.ONL==40000 



Address of QD ACP TCB 

ACP control and status word 

LUN used by ACP when doing I/O for this unit 

Count of transactions outstanding to ACP 

; Stop requested for ACP on this unit 
; This unit onlne 



.PSECT 



Q$$D11=3 
LD$QD=0 



Number of units 

Driver loadable 



.TITLE QDDAT 
.IDENT /01/ 

. ENABL LC 



D-12 



USER-WRITTEN ANCILLARY CONTROL PROCESSORS 



This structure is purely for purposes of example. It is not intended to 
be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 



**-QDDAT-QD: driver device tables 



The following data structure is designed with two things in mind: 

1. Providing the minimum structures to look like a disk 

2. Providing the minimum structures to satisfy the Executive 
and the MCR LOA commands. 



$QDDAT:: 
QDDCB : 



.WORD 

• WORD 
•ASCII 
.BYTE 

• WORD 
.WORD 





.QDO 

/QD/ 

0,Q$$D11-1 

QDND-QDST 





; Start of QDDRV device tables 

Link to next DCB 

Pointer to first UCB ' 

Device name 

Lowest and highest unit number > 

Length of UCB 

Pointer to driver dispatch table, set by LOA 



The following table defines the initial processing of I/O functions in the 
Executive QIO directive processing. The legal functions selected are those 
of the standard disk drivers. 



Legal functions 0.-15. 

Control functions 0.-15. 

No-op functions 0.-15. 

ACP functions 0.-15. 

Legal functions 16.-31. 

Control functions 16.-31. 

No-op functions 16.-31. 

ACP functions 16.-31. 

PCB address of driver partition 



WORD 


177037 


WORD 


000030 


WORD 


000000 


WORD 


177000 


WORD 


000777 


WORD 


000000 


WORD 


000000 


WORD 


000777 


WORD 






$$$=0 



QDST=. 



.NLIST MD 

•LIST ME 

. REPT Q$$D11 

, IRP XX,\<$$$> 

.IF DP M$$MUP 



.WORD 
.WORD 

. ENDC 



Start of UCB 



Login UIC, multi-user protection system 
Owning terminal UCB address 
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QD'XX' 


:.WORD 


QDDCB 




.WORD 


.QD'XX 




.BYTE 


UC.PWF!UC.ALG!3 




.BYTE 


US.MNT 




.BYTE 







.BYTE 







.WORD 


DV.MNTIDV.F1UDV 




.WORD 







• WORD 







.WORD 


512. 




.WORD 


$QD0 




.WORD 







.BLKW 


2 




.BLKW 


1 




.WORD 







.WORD 







.WORD 







.WORD 







.WORD 


'XX'+l 



Back pointer to DCB 
Redirect pointer 

Control flags byte, call on powerfail 
to allow proper setting of on-line/off-line bit 
Status byte 

Physical unit number, does not apply 
Second status word 
SDI"DV.DIR ; Characteristic word 1 
Characteristic word 2, size of device 
Characteristic word 3 
Characteristic word 4, buffer size 
Pointer to SCB 
Attached task TCB address 
User buffer pointer 
and byte count 

Address of file system ACP TCB 
Address of VCB for file system 
U.QACP-QDACP TCB address 
U.QCTL-QDACP Control word 
U.QLUN-QDACP LUN for I/O 



QDND=. 



End of UCB 



.ENDR 



$$$=$$$+1 



.ENDR 



$QD0: : 



.NLIST 


ME 




.LIST 


MD 




.WORD 


o,.- 


-2 


.BYTE 


0,0 




.BYTE 


0,0 




.BYTE 


0,0 




• WORD 







.WORD 







• BLKW 


5 





Device I/O queue 

Device priority and vector 

Current and initial device timeout count 

Controller index and device status 

CSR address 

Address of I/O packet 

Fork block 



$QDEND: 



End of QDDRV device tables 



, END 



.TITLE QDDRV 
, IDENT /01/ 

, ENABL LC 



This driver is purely for purposes of example. It is not intended to 
be a useful driver nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 



**-QDDRV-QD: driver 
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MACRO LIBRARY CALLS 



DRIVER DISPATCH TABLE 



$QDTBL: : .WORD 


QDINI 


.WORD 


QDCAN 


.WORD 


QDOUT 


.WORD 


QDPWF 


; LOCAL DATA 




.IF DF 


AUTOST 


ACPTNM: .RAD 50 


/QDACP / 


.ENDC 





Initiator entry point 
Cancel I/O entry point 
Device timeout entry point 
Powerfail entry point 



; Default ACP task name 



**-QDINI - "Disk" Driver 

This driver, in conjunction with its Ancillary Control Processor (ACP) 
appears to be a disk, but its operational characteristics are 
unusual. The actual storage medium may be any of a number of devices 
including memory, disk, or DECnet link. No driver queue is maintained; 
all I/O packets are queued directly to the ACP. The cancel I/O, device 
timeout, and powerfail entry points are all set to be no-ops. The actual 
processing of the request is left to the ACP. 

Remember, this driver is an example and demonstrates multiple features 
of the driver/ACP/Executive interface. 

Inputs: 

R5=UCB address 

The buffer address and count for IO.RLB and IO.WLB have been validated 

by DRQIO processing code. IO.KIL, 10. ATT, and IO.DET are processed by 

the Executive's standard I/O processing routines. IO.CTL is queued directly 

to QDACP. 



ENABL LSB 



QDINI: 



CALL 

BCS 

CLRB 

MOV 

BIT 

BEQ 

MOVB 

CMPB 

BEQ 

CMPB 

BNE 



; Driver initiation entry point 

$GTPKT ; Get I/O packet 

EXIT ; If CS none to get 

S.STS(R4) ; Unbusy controller since ACP does all work 

R1,R3 ; Copy I/O packet address 

#UQ.ONL,U.QCTL(R5) ; Unit online? 



20$ 

I.FCN+1 (R3) ,R0 

#IO.RLB/400,R0 

QPRLB 

#IO.WLB/400,R0 

ERRIFC 



If EQ no 

Get function code 

Read logical block? 

If EQ yes 

Write logical block? 

If NE no 
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Function specific validation routines. The checks here could 

be made later in the ACP, but they are easily made here and have 

the added benefit of saving of two context switches (to and from 
the ACP) to return an error. 



QPWLB : MOV 
BIT 
BNE 



QPRLB: CALL 

MOV 
MOV 



BNE 



#IE.WLK&377,R0 ; Assume write locked 

#DV. SWL,U.CW1(R5) ; Unit software write locked? 

I OF IN ; If NE yes 

; Join common code 



$BLKCK 
R3,R1 
U.QACP(R5) ,R0 



10$ 



; Check for valid logical blocks 

; Restore the I/O packet address to Rl 

; Get address of ACP's TCB. The offset U.ACP 

; can NOT be used since file system ACP uses 

; that location. The UCB is used for TCB 

; because it is easy for the ACP to access 

; (as opposed to some location within the 

; driver) . 

; If NE the ACP has been started. 

; The next few lines of code may be used as 

; an alternate method of starting the ACP. 

; They allow the ACP to be started 

; automatically if it is installed. 

; They can't be used in this application 

; since ACP needs some initialization info 



•IF DF AUTOST 



; If defined, auto start ACP 



10$: 



20$: 



MOV 

CALL 

BCS 

BIT 

BEQ 

MOV 

.ENDC 

INC 
JMP 



MOV 
BR 



ERRIFC: MOV 



I OF IN: CLR 
JMP 



#ACPTNM,R3 ; Get address of ACP task name 

$SRSTD ; See if our ACP is installed 

20$ ; If CS no 

#T3.ACP,T.ST3(R0) ; Built as an ACP? 
20$ ; If EQ no 

R0,U.QACP(R5) ; Save address of ACP 



U.QTRN(R5) 
$EXRQP 



#IE.OFL&377,R0 
IOFIN 

#IE.IFC&377,R0 



Rl 

$I0FIN 



Increment count of transactions in ACP queue 
Queue to the ACP by priority and activate 
it. This request will unstop the ACP if 
is stopped or run it if its not active. 

Reference label 

I/O status of device not ready 

Finish I/O request 

I/O status of illegal function code 
Finish I/O request 

Second I/O status word 
Finish I/O request 



.DSABL LSB 
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**-QDPWF-Powerfail, Mark offline units offline 



QDPWF: BIT #UQ.ONL, QCTL(R5) ; Unit offline? 

BNE 10$ ; If NE no 

BISB #US.0FL p U.5i2(R5) ; Set offline 

10$: ; Reference label 



**-QDCAN-Cancel I/O in progress, ignored 
**-QDOUT-Device timeout, does not apply 



QliCAN: 
QDOUT: 
EXIT: 



RETURN 

.END 



; These functions are no-ops 



• TITLE QDACP 
.IDENT /01/ 

.ENABL LC 



This ACP is purely for purposes of example. It is not intended to 
be a useful ACP nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 



**-QDACP-QD: driver ACP 



MACRO LIBRARY CALLS 



.MCALL ALUN$S,DIR$,QIO$,WTSE$,WSIG$S 



LOCAL DATA 



,QIO:: QIO$ 



,1,1,,I0SB,, <,,,,,> ; My own QIO DPB 



. IOST: : 
.IOPKT: 
.ACT UN: 


.BLKW 
:.BLKW 
: .WORD 


2 

1 



WTSE: 


WTSE$ 


1 


I0SB: 


.BLKW 


2 


FID: 


• BLKW 


3 



; I/O status to return to user 
; Address of current I/O packet 
; Count of active units 

; Wait for I/O completion 

; I/O status block for my I/O 

; File ID of work file 
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**-.START-ACP starting entry point 



.START:: CALL 



• INIT 



Do one-time initialization 



**-.GTPKT-Get the next I/O packet from ACP queue and dispatch function 



,GTPKT::CLR . IOPKT 
SWSTK$ 30$ 



MOV 


$TKTCB,R0 


ADD 


#T.RCVL,R0 


CALL 


$QRMVF 


BCC 


20$ 


TST 


.ACTUN 


BNE 


10$ 


MOV 


$TKTCB,R5 


JMP 


$DREXT 



10$: 



20$: 



30$: 



JMP 



MOV 
BEQ 

MOV 



$STPCT 



MOV Rl,. IOPKT 
RETURN 



. IOPKT, R3 

.GTPKT 

I.UCB(R3) ,R5 



No I/O packet yet 
Switch to system state to synchronize with 
Executive. This prevents context switching 
and makes Executive routines accessable. 
On return from system state, execution will 
resume at 30$. This call also saves all 
registers. 

Address of my TCB (must be my TCB since 
can't execute in context of any other task 
Point to receive queue listhead 
Attempt to dequeue I/O packet from queue 
If CC I/O packet removed from queue 
Is this ACP still active for any units? 
If NE yes 

R5 must be our TCB address 

No I/O requests in our queue and no active 
units, perform a task exit without any 
possibility of a race between QDCON 
inserting an I/O request in our queue 
and our task exit. 

Stop current task (us) and return to task 
state. Once back in task state the PC will 
be at 30$, since once we are unstopped we will 
resume execution at 30$, not the next line. 
Save I/O packet address. (Return to task 
state restores all registers.) 
Return to task state. Complementary to 
SWSTK$. 

Get I/O packet address 

If EQ none found in queue, try again since 

someone unstopped us. 

Get UCB address for request 



Process I/O request 

Do any initialization required 



40$: 



MOV 


#IS.SUC,.IOST 


CLR 


.IOST+2 


MOV 


#.QIO+Q.IOPL,R0 


MOV 


#6,R1 


CLR 


(R0) + 


DEC 


Rl 


BNE 


40$ 


MOV 


U.QLUN(R5) ,.QI0 



Initial status of success 

Point to parameter list are of our QIO DPB 
Number of words to clear 
Clear them 
Done? 
If NE no 
. IOLU ; Setup LUN in DPB 
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Dispatch function 

I/O function is dispatched with the following registers 

R5=UCB Address 
R3=I/0 Packet 

And .QIO has the correct LUN plugged into the DPB 



Get I/O function code 

Read logical block? 

If NE no 

Process read 

Write logical block? 

If NE no 

Process write 

ACP control function? 

If EQ yes 





MOVB 


I.FCN+1 (R3) ,R0 




CMPB 


#IO.RLB/400,R0 




BNE 


100$ 




JMP 


FCRLB 


100$: 


CMPB 


#IO.WLB/400,R0 




BNE 


110$ 




JMP 


FCWLB 


110$: 


CMPB 


#IO.CTL/400,R0 




BEQ 


FCCTL 



Illegal function code 
IEIFC: MOV #IE. IFC&377, . IOST ; I/O status of illegal function code 



**-. IOFIN-Finish I/O request returning status to user. 



INPUTS: 



. I0ST=I/0 status of current request 
,IOPKT=Address of I/O packet 



IOFIN: MOV 
MOV 
MOV 
MOV 
SWSTK$ 
CLR 
DEC 

BNE 
BIT 



BEQ 

BITB 

BEQ 

TST 

BNE 

BIC 

BISB 

CLR 

INC 

JMP 

ASR 

BCC 

CALL 

DEC 

JMP 



10$: 
20$: 

30$: 



.IOST,R0 

.I0ST+2,R1 

.IOPKT,R3 

I.UCB(R3) ,R5 

20$ 

. IOPKT 

U.QTRN(R5) 

10$ 
#UQ.STP,U.QCTL(R5 

10$ 

#US.MNT,U.STS(R5) 

10$ 

U.ATT(R5) 

10$ 

#UQ.STP!UQ.ONL,U 

#US.OFL,U.ST2(R5) 

U.QACP(R5) 

. IOPKT 

$IOFIN 

. IOPKT 

30$ 

.CLOSE 

.ACTUN 

.GTPKT 



Get I/O status 

Get address of I/O packet 
Get UCB address 

Switch to system state 

No I/O packet anymore 

Decrement count of outstanding I/O queued 

to ACP 

If NE more requests in queue 
) ; ; Has a request to stop processing on 

this unit been received? 

If EQ no 
; ; Unit still mounted? 

If EQ yes 

Unit attached? 

If NE yes 
QCTL(R5) ; Clear our on-line bit and stop 
; request flag 

; ; Mark unit offline 
; No ACP active on unit 

; Flag to indicate unit went to off-line state 
; Finish I/O request and return to task state 

Unit go to offline state? 

If CC no 

Close up shop on this unit 

Decrement count of active units 

Get next I/O request 
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**-.DOIO-Do I/O for user to real device 

This routine maps to the users buffer (s) and issues an I/O request that 

will use the requesting task's buffers. This occurs because the QIO 

processing uses the logical mapping, not the virtual mapping, to determine 

where buffers are located. By logical mapping, I mean the physical mapping 

contained in the memory management registers. Because we are privileged, 

no validity checking is made on the buffers, so it is possible to do I/O 

to buffers larger than the windows through which they are mapped, that is, greater 

than about 4KB. This routine will function properly if the ACP overmaps 

the I/O page because it switches to the system stack, hence to kernel mode. 

Therefore, this routine must not be mapped by APR 7. 

INPUTS: 

R0=Buffer 1 mapping for user APR 1 
Rl=Buffer 2 mapping for user APR 2 

OUTPUTS: 

I/O issued and completed 

If CC then IOSB is I/O status 

If CS then $DSW is directive error 



,DOIO: 



10$: 



SWSTK$ 


10$ 


MOV 


UISAR0+2,2(SP) 


MOV 


UISAR0+4,4(SP) 


MOV 


R0,UISAR0+2 


MOV 


Rl,UISAR0+4 


INCB 


$CXDBL 


RETURN 





Switch to system state 
Save user APR 1 value in saved R0 
And user APR 2 value in saved Rl 
Map to user's first buffer 
Map to user's second buffer 
Disable context switching 
Return to task state 
Reference label 



Issue the QIO directive, context switching is disabled so we don't have 
to worry about user APRs 1 and 2 being modified. However, we can't wait 
for the I/O to complete at this point. 



DIR$ 
ROR 



.QIO 
(SP) 



; Issue I/O request 
; Save carry state 



Buffers have been "validated" and relocated so we can restore original 
mapping and enable context switching. 



20$: 



SWSTK$ 


20$ 


MOV 


R0,UISAR0+2 


MOV 


Rl,UISAR0+4 


DECB 


$CXDBL 


RETURN 





Switch to system state 
Restore user APR 1 
Restore user APR 2 
Enable context switching 
Return to user state 
Reference label 



Context switching is now enabled, check directive status and if successful 
wait for completion 



ROL (SP)+ 

BCS 30$ 

DIR$ #WTSE 
30$: RETURN 



; Restore carry, was directive successful? 

; If CS no 

; Wait for I/O to complete 

; Return to caller 
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**-.BLXI -Transfer data into our buffer 

INPUTS: 

R0=Byte count to transfer 
Rl=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 

OUTPUTS: 

Data in our buffer 



,BLXI: 



. ENABL LSB 



SWSTK$ 


20$ 


MOV 


R0,R5 


MOV 


R1,-(SP) 


MOV 


R2,-(SP) 


MOV 


R3,R0 


CALL 


$REL0C 


MOV 


R1,R3 


MOV 


R2, R4 


MOV 


(SP) + ,R2 


MOV 


(SP)+,R1 


BR 


10$ 



Switch to system state 

Save R5 

Save Rl 

And R2 

Set virtual address of our buffer 

Convert to address double word 

Copy Rl and 

R2 to proper place for $BLXIO 

Restore R2 

and Rl 

Join common code 



**-.BLXO-Transfer out of our buffer into user's buffer 

INPUTS: 

R0=Byte count to transfer 
Rl=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 



; OUTPUTS: 






Data in 


user buffer 


.BLXO: 


SWSTK$ 


20$ 




MOV 


R0,R5 




MOV 


R3,R0 




MOV 


R1,R3 




MOV 


R2,R4 




CALL 


$RELOC 


10$: 


MOV 


R5,R0 




ADD 


#120000-140000, R2 




JMP 


$BLXI0 


20$: 


RETURN 


1 



Switch to system state 

Save RO 

Set R0 to address of our buffer for $RELOC 

Copy Rl and 

R2 into proper place for $BLXIO 

Convert to address doubleword 

Restore byte count 

; Convert to APR 5 displacement 

Transfer data and return to task state 

Return to caller 



.DSABL LSB 



D-21 



USER-WRITTEN ANCILLARY CONTROL PROCESSORS 



**-FCCTL-ACP control functions 

Two control functions are supported, start-up and shut-down. 

We check the request for validity and then set up various fields in the 
drivers UCB. 



FCCTL: MOV 
BIT 
BEQ 
CMPB 
BEQ 
CMPB 
BEQ 
BR 



I.TCB(R3),R0 ; Get TCB address of issuing task 
#T3.PRV,T.ST3(R0) ; Task privileged? 



IEIFC 

#1,I.FCN(R3) 

10$ 

#2,I.FCN(R3) 

30$ 

IEIFC 



; If EQ no 

; Startup request? 

; If EQ yes 

; Stop request? 

; If EQ yes 

; Illegal function 



; Process start request 



10$: TST U.QACP(R5) ; Already got an ACP? 

BNE 20$ ; If NE yes 

CALL .OPEN ; Open up shop for unit 

BCS 100$ ; If CS failed to open channel to "device" 

INC .ACTUN ; Increment count of units active 

MOV $TKTCB,U.QACP(R5) ; Set ACP TCB address in UCB 

BIS #UQ.ONL,U.QCTL(R5) ; Set unit online 

BICB #US.OFL,U.ST2 (R5) ; And for the operating system 

BR 100$ ; Join common code 

20$: MOV #IE.RSU&377, . IOST ; ACP already started for unit error 

BR 100$ f Join common code 

; Process stop request 



30$: 



40$: 

50$: 

60$: 
100$: 



CMP 

BNE 

BIT 

BNE 

CALL 

BITB 

BEQ 

TST 

BNE 

CMP 

BNE 

BISB 

BIS 

RETURN 

MOV 

RETURN 

MOV 
BR 

MOV 

JMP 



$TKTCB,U.QACP(R5) ; Unit online with correct ACP? 

50$ ; If NE no 

#UQ.STP,U.QCTL(R5) ; Stop requested? 

60$ ; If NE yes 

$SWSTK,100$ ;; Go to system state to prevent a race problem 

#US.MNT,U.STS(R5) ; ; Unit still mounted? 



40$ 

U.ATT(R5) 

40$ 

#1,U.QTRN(R5) 

40$ 



If EQ yes 

Unit attached? 

If NE yes 

Is this this the only transaction queued? 

If NE no 

#US.0FL, U.ST2 (R5) ; ; Mark unit off line to prevent further I/O 
#UQ.STP,U.QCTL(R5) ; ; Request unit be stopped 

; ; Return to task state at statement 100$ 
#IE.NFW&377, .IOST ; ; Unit busy, attached, or mounted 

;; Return to task state at statement 100$ 

#IE.0FL&377, .IOST ; Unit offline 
100$ ; Join common code 

#IE. FLN&377, .IOST ; Already being stopped; error 

.IOFIN ; Finish I/O request 
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WARNING 



The above code must be in the first 8K of the ACP because 
a switch to system state uses the kernel mode mapping which 
allows only 8K for task mapping. (The I/O page is mapped in 
thru APR 7 in system state, but may be overlaid by the task 
in task state.) 



**-FCRLB-Read logical block function 



FCRLB: 



. ENABL 


LSB 


CALL 


.READ 


BCS 


10$ 


MOV 


I.PRM+4 (R3) ,R0 


MOV 


R0,.IOST+2 


MOV 


I.PRM(R3) ,R1 


MOV 


I.PRM+2(R3) ,R2 


MOV 


R4,R3 


CALL 


.BLXO 


BR 


30$ 



Data in memory already? 

If CS no 

Get byte count 

Set return status byte count 

APR mapping 

APR6 displacement 

Address of our buffer 

Transfer to user buffer 

Join common exit code 



**-FCWLB-Write logical block function 



FCWLB : 



CALL 


.WRITE 


BCS 


10$ 


MOV 


I.PRM+4 (R3) ,R0 


MOV 


I.PRM(R3) ,R1 


MOV 


I.PRM+2 (R3) ,R2 


MOV 


R4,R3 


CALL 


.BLXI 


MOV 


.IOPKT,R3 



Transfer data to our buffer first? 

If CS no 

Get byte count 

APR mapping 

APR6 displacement 

Address of our buffer 

Transfer to our buffer 

Restore I/O packet address 



Do I/O from user buffer 



10$: 



20$: 
30$: 



MOV 
MOV 
SUB 
MOV 

CALL 

BCC 

MOV 

BR 
MOV 
MOV 
JMP 



I.PRM(R3),R0 ; Get mapping value for APR 1 
I.PRM+2 (R3) ,R1 ; Get displacement biased for APR6 
#140000-20000, Rl ; Adjust to an APR1 bias 

Rl, .QIO+Q. IOPL ; Insert virtual address of buffer when mapped 
; via APR 1 

Issue I/O request 

If CC successful 

; Return error to user 

Join common code 

Return status to user 



.DOIO 

20$ ; 

#IE.ABO&377,.IOST 

30$ 

IOSB, .IOST 

IOSB+2, .IOST+2 

.IOFIN 



Finish I/O request and dispatch next request 



.DSABL LSB 
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**-.INIT-One time initializations on startup 



INIT: 



; None 



RETURN 



**-.OPEN-Open up I/O path for unit 



Inputs: 



R5=UCB address 
R3=I/0 packet address 



OPEN: 



10$: 
20$: 



ALUN$S 

BCS 

MOV 

MOV 

MOV 

MOV 

CALL 

MOVB 

BMI 

CLR 

CLR 

MOV 

MOV 

CALL 

MOVB 

BMI 

CLR 

MOV 

CALL 

MOV 

RETURN 

SEC 

RETURN 

CRASH 



U.QLUN(R5) ,#"SY,#0 ; Assign LUN to work file device 

20$ ; If cs error 

#10. CRE, .QIO+Q.IOFN ; Setup for create file 

#FID, .QIO+Q.IOPL ; Insert address to receive file ID 

#100000, .QIO+Q.IOPL +4 ; Enable extend 

I PRM(R3) ,.QI0+Q.I0PL+6 ; Allocate file of size requested 



XI O 

IOSB, .IOST 

10$ 

.QIO+Q.IOPL +4 

.QIO+Q.IOPL +6 



Create and extend file 

Copy I/O status 

If MI error 

Reset parameter 

Ditto 
#10. ACW,. QIO+Q.IOFN ; Set up to access the file 
#100000, .QIO+Q.IOPL+10 ; Enable access 
XIO ; Access file 

IOSB,. IOST ; Copy I/O status 
10$ ; If MI error 

.QIO+Q.IOPL+10 ; Reset parameter 

#10. DEL, .QIO+Q.IOFN ; Set up to mark file for delete 
Xio ; Mark file for delete 

I.PRM(R3) ,U.CW3(R5) ; Set up device size 

; Successful exit with carry clear 
; Error exit with carry set 



; Internal error 



**-.CLOSE-Close channel to device 



.CLOSE: MOV 
MOV 

10$: CLR 
DEC 
BNE 
MOV 
JMP 



|6, R0 ; Number of parameters to clear 

#.QIO+Q.IOPL,Rl ; Address of parameter list 

(Rl)+ ; Reset parameters 

R0 ; Done? 

10$ ; If NE no 

#10. DAC, .QIO+Q.IOFN ; Set to deaccess file 

XIO ; Deaccess file 



**-. READ-Determine method of performing read 

Inputs: 

R5=UCB Address 
R3=I/0 Packet 
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Outputs: 

If CS then do I/O directly into user buffer 

.QIO DPB setup with I/O function code 
If CC then do I/O to our buffer, then copy to user buffer 
R4=Address of buffer 



.READ: 



10$: 



MOV 

MOV 

MOV 

MOV 

ADD 

ADC 

CMF 

BNE 

MOV 

MOV 

CALL 

TSTB 

BMI 

CLC 

RETURN 

SEC 

RETURN 



#10. RVB,. QIO+Q.IOFN ; Set up to read 
I.PRM+4 (R3) ,.QI0+Q.I0PL+2 ; Insert byte count 
I. PRM+10 (R3) , .QIO+Q. IOPL+6 ; And block number 
I.PRM+12(R3) ,.QIO+Q.IOPL+10 ; 



into DPB 
to start 



transfer 



#1,. QIO+Q. IOPL+10 

.QIO+Q. IOPL+6 

#1000, I.PRM+4 (R3 

10$ 

#.BUF,R4 

R4, .QIO+Q. IOPL 

XIO 

IOSB 

10$ 



Convert from "logical" to "virtual" 



fircf? 



If NE no 

Set address of buffer 

Set up buffer address 

Read data into our buffer 

On error go directly to user buffer; error? 

If MI yes 

Copy to user buffer 

Do I/O directly to user buffer 



**-.WRITE-Determine method of performing write 

Inputs: 

R5=UCB Address 
R3=I/0 Packet 

Outputs: 

If CS then do I/O directly from user buffer 

.QIO DPB setup with I/O function code 
If CC then copy data to our buffer, then do I/O from user buffer 

R4=Address of buffer 



.WRITE: 



10$: 



MOV 

MOV 

MOV 

MOV 

ADD 

ADC 

CMP 

BNE 

MOV 

CLC 

RETURN 

SEC 

RETURN 



#IO.WVB, .QIO+Q.IOFN ; Set up to write 

I.PRM+4 (R3) , .QIO+Q. IOPL+2 ; Insert byte count into DPB 

I. PRM+10 (R3) ,. QIO+Q. IOPL+6 ; And block number on device 

I. PRM+12 (R3) ,. QIO+Q. IOPL+10 ; 

#1, .QIO+Q. IOPL+10 ; Convert from "logical" to "virtual" 

.QIO+Q. IOPL+6 ; 

#1000, I.PRM+4 (R3) ; Copy to our buffer first? 



10$ 
#.BUF,R4 



If NE no 

Address of buffer for data 

Copy from user buffer 

Do I/O directly from user buffer 
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**-X 10 -Execute QIO request 



XIO: 



10$: 



20$: 



DIR$ 


#.QIO 


BCC 


10$ 


CMP 


#IE.UPN,$DSW 


BNE 


20$ 


WSIG$S 




BR 


XIO 


DIR$ 


#WTSE 


BCS 


20$ 


RETURN 





CRASH 



Issue I/O request 

If CC successfully issued 

No dynamic storage available? 

If NE no 

Hope 

. . .hope 

Wait for I/O to complete 

If CS error 



; Internal error 



I/O buffer 



,BUF: .BLKB 1000 

. END . START 



; One block long 



• TITLE QDCON 
.IDENT /01/ 

.ENABL LC 



This control task is purely for purposes of example. It is not intended to 
be a useful task nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 



**-QDCON-QD: driver and ACP control task 



MACRO LIBRARY CALLS 



.MCALL ALUN$,GLUN$,DIR$,GMCR$,WTSE$S,QIOW$S,EXST$S 
.MCALL ISTAT$, STATE $,TRAN$ 



DEFINE PARSER STATE TABLE 

The following commands are supported: 

>QDC START QDn:/SIZE:n 

START is the subcommand to startup the ACP specifying the "disk size" 

>QDC STOP QDn: 



where 



where 



STOP is the subcommand to stop the ACP at the earliest opportunity 
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ISTAT$ QDCSTB , QDCKTB 

; Skip command name 

STATE$ INITL 
TRAN$ $STRNG 

; Determine subcommand 

STATE $ 

TRAN$ "START" , START, ,$START,$DISPT 

TRAN$ "STOP" , STOP, ,$STOP,$DISPT 

; Process START command, get device name 

STATE $ START 
TRAN$ "DEVICE 

STATE $ OPTION 
TRAN$ '//SWITCH 

TRAN$ $EOS,$EXIT 

STATE $ SWITCH 
TRAN$ "SIZE", SIZE 

STATE $ SIZE 
TRAN$ '= 

STATE$ 

TRAN$ $NUMBR, OPTION, SETSIZ 

; Process STOP command 

STATE$ STOP 
TRAN$ ! DEVICE 

STATE$ 

TRAN$ $EOS,$EXIT 

; Process device name 

STATE $ DEVICE 

TRAN$ $ALPHA, ,SETDV1 

STATE$ 

TRAN$ $ALPHA, ,SETDV2 

STATE $ 

TRAN$ $NUMBR,DEV1,SETUNT 

TRAN$ $ LAM DA 

STATE$ DEVI 
TRAN$ ' :,$EXIT 

; Terminate state table 

STATE $ 
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PARSER ACTION ROUTINES 



; Set first character of device name 

SETDV1: MOVB .PCHAR,$DEV ; Save first character of device name 

RETURN ; 

; Set second character of device name 

SETDV2: MOVB . PCHAR, $DEV+1 ; Save second character 

RETURN 

; Set device unit number 

SETUNT: MOV .PNUMB,$UNIT ; Save converted unit number 

RETURN ; 

; Set device size 

SETSIZ: MOV .PNUMB,$SIZE ; Save converted size 

RETURN 



LOCAL DATA 



ALUN: 
$DEV= 
$UNIT= 



ALUN$ 1,, 
ALUN+A.LUNA 
ALUN+A.LUNU 



GLUN: GLUN$ 1,GLUBUF 

GLUBUF: .BLKW 6 
$PDEV= GLUBUF+G.LUNA 
$PUNIT= GLUBUF+G.LUNU 
$CHAR= GLUBUF+G.LUCW 

GMCR: GMCR$ 

$SIZE: .WORD 

$DISPT: .WORD 

ACPNAM: .RAD50 /QDACP / 

PRMLST: .BLKW 8. 

$IOST: .BLKW 2 



Assign LUN to QDn: 
Address of device name 
Address of device unit number 

Get LUN information for QD: device 

LUN information buffer 
Actual device name 
Actual device unit 
Device characteristics word 

Get MCR command line 

Device size to create 

Address of service routine 

Name of ACP 

Parameter list for I/O packet 

I/O status 



Error messages 



MACRO 


ERM 


ERN,STS 
.PSECT 


,TEXT 
$$ERMG 




$$$1=. 


.ASCII 


<15>"TEXT" 




$$$2=. 


.PSECT 






ERN: 


.WORD 
.WORD 


STS 
$$$1,$$$2-$$$1 


EN DM 
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.MACRO 



EN DM 



■MACRO 



EN DM 



.MACRO 



.EN DM 

ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 



ERRX ERN 
MOV #ERN,R0 
JMP $ERRXT 



FTLX ERN 
MOV #ERN,R0 
JMP $SUCXT 



SUCX ERN 
MOV #ERN,R0 
JMP $SUCXT 



ERRCML, 14,<%QDC-F-GETCOMFAIL, Failed to get command line> 
ERRSYN,24,<%QDC-F-SYNERR, Syntax error in command> 
ERRNQD,34,<%QDC-F-NOQDDEV, Failed to assign LUN to QD:> 
ERRBDV, 44,<%QDC-F-BADDEVICE, Invalid device specified> 
ERRNOD, 54,<%QDC-F-NOPOOL, No dynamic memory for I/O request> 
ERRNAC,64,<%QDC-F-NOACP,QDACP not installed in system> 
ERRREQ,74,<%QDC-F-REQFAIL, Failed to request QDACP> 
ERRUSE,104,<%QDC-F-DEVINUSE, Specified unit already in use> 
ERRINT,114,<%QDC-F-INTERNAL, Internal error) 

ERRFLN, 124,<%QDC-F-OFFLINREQ, Unit already requested to offline) 
ERRNOL, 134,<%QDC-F-NOTONLINE, Unit not online) 
ERRNDS, 144,<%QDC-F-NODISSPAC, Failed to allocate disk space) 
ERRBSY, 154,<%QDC-F-DEVICEBUSY, Device busy, mounted, or attached) 
ERRFTL, 0,<-QDC-F-ONLFAIL, Failed to bring unit online) 
SUCCOM,l 61, <%QDC-S -ONLINE, Specified unit brought online) 
REQOFF, 171,<%QDC-S-REQ0FFLINE, Unit requested to offline) 



**-.QDCON-QD device control program 



$QDCON: CLR 
CLR 
DIR$ 
BCC 
FTLX 



10$: 



20$: 



30$: 



CLR 

MOV 

MOV 

MOV 

MOV 

CALL 

BCC 

FTLX 

DIR$ 

BCC 

FTLX 

DIR$ 

JMP 



$DISPT 

$UNIT 

#GMCR 

10$ 

ERRCML 

Rl 

#QDCKTB,R2 

$DSW,R3 

#GMCR+G.MCRB,R4 

#INITL,R5 

.TPARS 

20$ 

ERRSYN 

#ALUN 
30$ 

ERRNQD 

#GLUN 
@$DISPT 



Reset service routine dispatch address 
Clean out unit number 
Get the command line 
If CC successful 



Suppress blanks 

Get keyword table address 

Get length of command line 

Get address of command line 

Get address of initial parser state 

Parse command line 

If CC good command line 



; Assign LUN to QD: 
; If CC good device 



; Get device information 

; Dispatch to START or STOP service 
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; **-$START-Start up ACP and specify size 



$START: CMP 
BEQ 
FTLX 



10$: 



20$: 



30$: 
40$: 

100$: 



110$: 
120$: 
130$: 



MOV 
MOV 
MOV 
MOV 

CALL 

BCC 

CMP 

BNE 

ERRX 

CMP 

BEQ 

CMP 

BNE 

ERRX 

ERRX 

CMPB 
BNE 

sucx 

CMPB 

BNE 

ERRX 

CMPB 

BNE 

ERRX 

FTLX 



# n QD,$PDEV 

10$ 

ERRBDV 

$SIZE,PRMLST 
#PRMLST,R4 
#ACPNAM,R3 
#IO.CTL!l,R2 

.QUE 10 

100$ 

#IE.UPN,$DSW 

20$ 

ERRNOD 

#IE.INS,$DSW 

30$ 

#IE.PRI,$DSW 

40$ 

ERRNAC 

ERRREQ 

#IS.SUC,$IOST 

110$ 

SUCCOM 

#IE.RSU r $IOST 

120$ 

ERRUSE 

#IE.DFU,$IOST 

130$ 

ERRNDS 

ERR INT 



; Really QD:? 
; If EQ yes 



; Address of parameter 

; Get address of parameter list 

; Get address of ACP task name 

; Set function code of ACP control 

; and subf unction of START (1) 

; Queue an I/O request to the ACP 

; If CC successfully queued 

; No pool? 

; If NE no 

; ACP not installed? 
; If EQ yes 
; Not an ACP? 
; If NE no 

; Catchall error message 

; Success? 
; If NE no 
; Successful completion 

; Already got an ACP or already started? 
; If NE no 

; Device full? 
; If NE no 

; Catchall error message 



**-$ST0P-Stop ACP operation 



$ST0P: CMP #"QD,$PDEV 

BEQ 10$ 

FTLX ERRBDV 

10$: MOV #PRMLST,R4 

MOV #ACPNAM,R3 

MOV #I0.CTLI2,R2 

CALL .QUEIO 

BCC 100$ 

CMP #IE.UPN,$DSW 

BNE 140$ 

FTLX ERRNOD 

100$: CMPB #IS.SUC,$IOST 

BNE 110$ 

SUCX REQOFF 

110$: CMPB #IE.FLN,$IOST 

BNE 120$ 

FTLX ERRFLN 



Really QD:? 
If EQ yes 



Get address of parameter list 

Get address of ACP task name 

Set function code for ACP control 

and subfunction of STOP (2) 
Queue an I/O request to the ACP 
If CC successfully queued 
No pool? 
If NE no 



; Success? 

; If NE no 

; Successful completion 

; Already being off-lined? 

; If NE no 
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120$: CMPB #IE.NFW,$IOST 

BNE 130$ 

FTLX ERRBSY 

130$: CMPB #IE.OFL,$IOST 

BEQ 140$ 

FTLX ERRINT 

140$: FTLX ERRNOL 



; Unit busy? 
; If NE no 

; Device not on line? 
; If EQ yes 

; Catchall error message 
; Not on line 



**-.QUEIO- Create and queue an I/O packet directly to an ACP 

This routine builds an I/O packet and queues it directly to an 
ACP bypassing the Executive QIO directive processing. The primary 
reason for doing this is the fact that under some circumstances 
the ACP cannot be reached by going through the driver, such as when the 
ACP has not been started. The parameter list is copied into the I/O packet 
without modification. Consequently, a buffer address cannot be passed 
as a parameter; it must first be relocated and the address double word 
placed in the parameter list; this routine is not designed to do that. 

INPUTS: 

R4=Parameter list address 

R3=Address of ACP task name 

R2=I/0 function code 

LUN 1 assigned to device associated with ACP 

OUTPUTS: 

If CC ACP requested and I/O complete 

$I0ST is I/O status block containing return from ACP 
If CS ACP not requested 

$DSW is error status 
IE.UPN - No dynamic memory for I/O packet 
IE. INS - ACP not installed 
IE.PRI - Task not an ACP 

If entry at .QUEIO, all registers preserved 



, QUEIO: 



10$: 



. ENABL 


LSB 


SWSTK$ 


4 0$ 


CLR 


$IOST ;; 


CLR 


$IOST+2 ;; 


MOV 


$HEADR,R5 


MOV 


H.LUN(R5),R5 


MOV 


#IE.INS,$DSW 


CALL 


$SRSTD 


BCS 


30$ 


MOV 


#IE.PRI,$DSW 


BIT 


#T3.ACP,T.ST3 (R0) 


BEQ 


30$ 


MOV 


R0,-(SP) 


MOV 


R2,-(SP) 


MOV 


#IE.UPN,$DSW 


MOV 


#I.LGTH,R1 ; ; 


CALL 


$ALOCB 


BCS 


30$ 


MOV 


(SP) + ,R3 


MOV 


R0,-fSP1 :; 


ASR 


Rl 


CLR 


(R0) + 


DEC 


Rl 


BNE 


10$ ; ; 


MOV 


#$IOST,R0 



Switch to system state 
Clear I/O status block 
Indicating I/O pending 
Get address of our task header 
Get device UCB address 
Assume task not found 
Search for task 
If CS failure 
Assume task not an ACP 
; ; Task an ACP? 
If EQ no 

Save TCB address 
Save I/O function code 
Assume buffer allocation failure 
Length of I/O packet 
Allocate buffer from pool 
If CS failure 
Restore R3 

Save address of I/O packet 
Convert size in bytes to words 
Zero I/O packet 
Done? 
If NE no 
Get I/O status block address 
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20$: 



30$: 
40$: 



50$: 



CALL 

MOV 

MOV 

MOV 

MOV 

MOV 

MOVB 

MOVB 

MOV 

MOV 

MOV 

ADD 

MOV 

MOV 

DEC 

BNE 

MOV 

INC 

CALL 

MOV 

INCB 

CLR 

MOV 

RETURN 

TST 

SEC 

BLE 

WTSE$S 

RETURN 



$RELOC 
{SP)+,R0 
#$IOST,I.IOSB(R 
Rl,I.IOSB+2 (RO) 
R2,I.IOSB+4 (RO) 
$TKTCB,I.TCB(RO 
#1,I.EFN(R0) 
#251.,I.PRI(R0) 
R5,I.UCB(R0) 
R3,I.FCN(R0) 
R0,R1 
#I.PRM,R0 
#8. ,R2 
(R4)+,(R0)+ 
R2 
20$ 

(SP) + ,R0 
U.QTRN(R5) 
$EXRQP 

$TKTCB,R0 
T.IOC(RO) 
T.EFLG(RO) 
#IS.SUC,$DSW 

$DSW 

50$ 

#1 



; ; Relocate it 
; ; Restore packet address 
0) ; ; Insert virtual address of status block 
; ; Insert relocation bias and 
; ; Offset of I/O status block 
) ; ; Insert our TCB 

t Insert event flag number 
: Insert priority 
r Insert device UCB 
r Insert function code 
: Copy address of packet 
r Point to parameter area 
; Set parameter count 
' Copy parameter list into packet 
; Done? 
; If NE no 

; Get ACP TCB address 

; Bump count of transactions queued to unit 
; Queue I/O packet to ACP by priority and 
; ensure ACP is active 
; Get our TCB address 
; Bump our I/O count 
; Clear event flag 1 
; Indicate success 
; Return to task state 
QIO successful? 
Assume error 
If LE no 

Wait for I/O to finish 
Return to caller 



.DSABL LSB 



**-$ERRXT -Error exit 
**-$SUCXT -Success exit 

Inputs: 

R0=Error table entry' 

Outputs: 

Message and task exit 





. ENABL 


LSB 


$ERRXT: 


MOV 


(R0)+,R5 




MOV 


(R0) + ,R1 




MOV 


(R0) + ,R2 




QIOW$S 


#IO.WVB,#5,# 




BCC 


10$ 




IOT 




10$: 


MOV 


#ERRFTL+2,R0 




BR 


20$ 


$SUCXT: 


MOV 


(R0) + ,R5 


20$: 


MOV 


(R0) + ,R1 




MOV 


(R0) + ,R2 




QIOW$S 


#IO.WVB r #5,# 




BCC 


30$ 




IOT 




30$: 


EXST$S 


R5 




.DSABL 


LSB 




• END 


$QDCON 



Get exit status 
Get address of error text 
Get size of text 
<R1,R2, 40> ; Write message 



Get address of fatal error message 
Join common code 
Get exit status 
Get address of final message 
Get size of message 
<R1,R2, 40> ; Write message 



; Exit with status 
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$ACHCK routine, 5-2 
$ACHKB routine, 5-2 
ACP, 

See Ancillary Control 
Processor 
ACP I/O function mask, 4-12 
Address doubleword, A-l 
$ALOCB routine, 5-3 
Alternate CLI support, 

UCB field, 4-25 
Ancillary Control Processor 
(ACP) , D-l 

as extension of Executive, 
D-5 

as task, D-4 

attributes, D-4 

enabling and disabling 
capacity, D-5 

example, D-ll 

for class of devices, D-4 

I/O request flow, D-5 

processing, D-6 

role of, in I/O processing, 
2-3 

shareability, D-5 

type, D-2 to D-3 
$ASUMR routine, 5-4, B-3 



Buffer, 

special, 6-9 



Cancel I/O entry point, 2-4 

DDT conditions, 4-10 
CDA, 

See Crash Dump Analyzer 
CINT$ directive, 3-1 
CLI Parser Block (CPB) , 

address in UCB, 4-25 
$CLINS routine, 5-5 
Conditional assembly symbol, 

LD$xx, 3-5 
Conditional routine, 5-1 
Control and status register 
(CSR), 

address in SCB, 4-22 
Control I/O function mask, 

4-12 
Controller number, 2-14 
CPB, 

See CLI Parser Block 
Crash Dump Analyzer (CDA) , 

debugging driver code, 3-20 



$CRAVL symbol, 

use of, in fault tracing, 
3-28 
CSR, 

See Control and status 
register 



Data base, driver, 

accessing shared, 2-9 
changing, 3-3 
controlling access to 

shared, 2-10 
example, 6-2 to 6-4 
loadable, 

See Loadable data base 
overview, 3-5 
resident, 

See Resident data base 
Data structure, 2-7 
See also System data 
structure macro 
definition 
ACP interface, D-7 
DH11 terminal multiplexer, 

2-7 
figure, 2-19 

interaction with driver, 2-5 
interrelationship, 2-18 
macro definition, 
overview, 4-1 
RL11 disk, 2-8 
summary, 2-20 
D$$BUG label, 3-19 
DCB, 

See Device Control Block 
DDT, 

See Driver Dispatch Table 
$DEACB routine, 5-6 
Debugging, 
CDA, 3-20 
Executive stack and register 

dump routine, 3-16 
fault code, 3-26 
fault isolation, 
3-20 to 3-23 
fault tracing, 3-23 to 3-28 
Panic Dump routine, 

3-19 to 3-20 
XDT, 3-15, 3-17 to 3-18 
Debugging aid, 3-16 
$DEUMR routine, 5-7, B-3 
$DEVHD word, 2-19 

role of, in I/O data 
structure, 2-20 
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Device Control Block (DCB) , 
description, 4-7 
relationship of, with I/O 

control blocks, 2-6 
required field, 3-6 
role of, in I/O data 

structure, 2-20 
with ACP, D-9 
Device Control Block (DCB) 
field, 
D.DSP, 3-6, 4-10, 4-14 
D.LNK, 3-6, 3-8, 4-8 
D.MSK, 3-6, 4-11 
D.NAM, 3-6, 4-9 
D.PCB, 3-6, 4-14 
D.UCB, 3-6, 3-8, 4-8 
D.UCBL, 3-6, 4-9 
D.UNIT, 3-6, 4-9 
Device interrupt entry point, 

2-4 
Device interrupt vector, 4-33 

definition, 2-10 
Device time-out entry point, 
2-4 
DDT conditions, 4-11 
Directive Parameter Block 
(DPB) , 2-5 
description, 4-6 
source of I/O packet 
information, 2-9 
DPB, 

See Directive Parameter Block 
Driver , 

changing code, 
debugging, 

See Debugging 
function, 1-2 
loadable, 

See Loadable driver 
multicontroller , 2-10 
Non-MASSBUS NPR, B-l 
postinitiation service, 2-11 
preinitiation processing of, 

2-11 
process-like characteristic, 

2-13 
property, 1-2 
rebuilding and 

reincorporating, after 
debugging, 3-29 to 3-30 
resident, 

See Resident driver 
role of, in RSX-11M, 2-5 
Software Performance Report 

(SPR) support, 3-4 
SYSGEN support, 3-1 
type, 1-1 



Driver code, 

changing, 3-3 

example, 6-4 to 6-9 

overview, 3-4 
Driver data base, 

See Data base, driver 
Driver Dispatch Table (DDT) , 

address, 3-5 

role of, in I/O data 
structure, 2-20 
Driver entry point, 

cancel I/O, 2-4, 4-10 

device interrupt,2-4 

device time-out, 2-4, 
4-11 

I/O initiator, 2-4, 2-12, 
4-10 

power failure, 2-4, 4-11 
Driver global symbol, 

$xxINP, 3-5 

$xxINT, 3-5 

$xxOUT, 3-5 

$xxTBL, 3-5 
DRQIO module, 

service performed in 

processing QIO, 2-11 
$DVMSG routine, 5-8 



Error logging, 

modifying driver to 

incorporate, 3-5 
SCB field, 4-20 
UCB field, 4-24 to 4-25 
Executive Crash Dump routine, 

3-20 
Executive Debugging Tool 
(XDT) , 
debugging driver code, 

3-17 to 3-18 
ODT features and commands 
not included, 3-17 
Executive service, 

driver processing, 2-10 
postinitiation, 2-11 
preinitiation, 2-11 
Executive service calls, 

5-1 to 5-28 
Executive stack and register 
dump routine, 3-17 
debugging driver code, 

3-16 
use of, in fault tracing, 
3-25 
$EXRQP routine, 5-9 
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F11ACP, 

role of, in I/O data 
structure, 2-19 
Fault code, 3-26 
Fault isolation, 3-20 to 3-23 
Fault tracing, 3-23 to 3-24 
after unintended loop, 3-28 
Executive stack and register 

dump, 3-25 to 3-27 
hints, 3-28 to 3-29 
in new driver, 3-28 
when processor halts without 
display, 3-27 
FCP, 

See File Control Processor 
FCS, 

See File Control Services 
File Control Block (FCB) , 
role of, in I/O data 
structure, 2-20 
File Control Processor (FCP) , 
role of, in I/O data 
structure, 2-19 
File Control Services (FCS), 
position of, in I/O 
hierarchy, 2-2 
Fork block, 

storage words in SCB, 4-23 
Fork level processing, 2-15 
Fork list, 2-9 
Fork process, 2-9 

creating with $F0RK, 2-12 
$F0RK routine, 5-10 

accessing shared driver data 

base, 2-10 
initiating fork process, 2-9 
$F0RK1 routine, 5-11 
Function mask word, 
See I/O function mask 



Global label, 

$USRTB, 3-13 

$xxDAT, 3-9 

$xxEND, 3-9 

$xxTBL, 4-10 
$GTBYT routine, 5-12 
$GTPKT routine, 2-12, 5-13 

in driver processing, 2-17 

use of, with ACP, D-6 
$GTWRD routine, 5-14 

conditional assembly, 5-1 

inclusion of, by SYSGEN, 3-2 



:?HEADR pointer, 

use of, in fault tracing. 



$HEADR pointer (Cont.) 
3-24 



ICB, 

See Interrupt Control Block 
Interrupt Control Block (ICB) , 

3-2, 4-35 
Interrupt entry point, 

address, 3-5 
Interrupt processing, 
fork level, 2-9, 2-15 
priority 7, 2-14 
priority of interrupting 
source, 2-14 
INTSV$ macro, 

description, 4-35 
format, 4-35 
$INTSV routine, 2-12, 5-15 
calling with INTSV$ macro, 

4-35 
processing at priority of 
interrupting source, 
2-15 
$INTXT routine, 5-16 
I/O control blocks, 

interrelationship, 2-6 
I/O data structure, 
See also System data 
structure macro 
definition 
See Data structure 
I/O driver. 

See Driver 
I/O function mask, 
ACP, 4-12 
control, 4-12 
creating, 4-13 
legal, 4-12 
no-op, 4-12 

values for disk drive, 4-16 
values for magtape drive, 

4-17 
values for standard 
functions, 4-15 
values for unit record 
device, 4-18 
I/O hierarchy, 2-1 
I/O initiator entry point, 
2-4, 2-12 
DDT conditions, 4-10 
I/O packet, 2-8 
description, 4-2 
format, 4-3 
pointer in SCB, 4-21 
with ACP, D-7 
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LAST, 4-5 
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I/O packet field (Cont.) 

I.EFN, 4-3 

I.FCN, 4-4 

I.IOSB, 4-4 

I.LNK, 4-2 

I.PRI, 4-3 

I.PRM, 4-5 

I.TCB, 4-4 

I.UCB, 4-4 
I/O philosophy, 2-1 
I/O processing, 

ACP, 2-3 

QIO directive, 2-3 
I/O queue, 2-9 
I/O request, 

flow, 2-16 to 2-17 
$IOALT routine, 2-13, 5-17 
$IODON routine, 2-13, 5-17 
$IOFIN routine, 5-18 

use of, by ACP, D-7 



LD$xx symbol, 3-5 

required by INTSV$ macro, 

4-35 
Legal I/O function mask, 4-12 
LOA command, 4-35 

action if UC.PWF set, 2-4 
effect of, when loading 

driver, 3-8 
loading driver, 3-2, 3-12 
Loadable data base, 
advantage, 3-8 
assembling, 3-9 
characteristics, 3-8 
Loadable driver, 
assembling, 3-9 
benefit, 1-1 
combination with data base, 

3-1 
debugging, 3-8 
definition, 1-1 
incorporating, with data 

base, 3-8 
linking, with loadable data 

base, 3-3 
linking, with resident data 

base, 3-3 
loading, into memory, 3-2, 

3-12 
rebuilding and 

reincorporating, after 

debugging, 3-30 
removing, from memory, 3-2 
task-building, 

mapped system, 3-10 
unmapped system, 3-11 



Loadable driver (Cont.) 

task-building, with resident 
data base, 3-12 
Logical unit number (LUN) , 
2-19 
preinitiation processing of, 
2-11 
Logical Unit Table (LUT) , 2-19 
LUN, 

See Logical unit number 
LUT, 

See Logical Unit Table 



Mapping register assignment 
block, 
allocating, B-2 
figure, B-3 
$MPUB1 routine, 5-20, B-3 

use of, to obtain UMRs, B-l 
$MPUBM routine, 5-19, B-3 

use of, to obtain UMRs, B-l 
Multicontroller driver, 2-10 
conditional code 

description, 4-33 
conditional code example, 
4-34 



No-op I/O function mask, 4-12 
NPR device driver, B-l 

use of SCB field S.MPR, 4-23 
N$$UMR symbol, B-4 



Panic Dump routine, 3-19 

sample output, 3-20 
Partition Control Block (PCB) , 

address in DCB, 4-14 
$PKAVL symbol, 

use of, in fault tracing, 
3-28 
Power failure entry point, 2-4 

DDT conditions, 4-11 
Process , 

state, 2-10 
Programming convention, 2-13 
Programming protocol, 2-14 

summary, 2-16 
$PTBYT routine, 5-21 
$PTWRD routine, 5-22 

conditional assembly, 5-1 

inclusion of, by SYSGEN, 3-2 
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$QINSP routine, 5-23 
QIO directive, 

position of, in I/O 

hierarchy, 2-2 
preinitiation processing of, 

2-11 
role of, in I/O processing, 
2-3 
QIO Directive Parameter Block, 

4-6 
$QRMVF routine, 5-24 
use of, with ACP, D-6 



Record Management Services 
(RMS) , 
position of, in I/O 
hierarchy, 2-2 
RED command, 2-6 
$RELOC routine, 5-25 
Resident data base, 
assembling, 3-12 
example, 6-1 
Resident driver, 
assembling, 3-13 
combination with data base, 

3-1 
definition, 1-1 
example, 6-1 
incorporating, 3-13 
linking data base, 3-3 
rebuilding and 

reincorporating, after 
debugging, 3-29 
task-building, 3-14 
RMS, 

See Record Management 
Services 



SCB, 

See Status Control Block 
Special buffer handling, 6-9 

example, 6-9 to 6-11 
SST fault, 

abnormal, 3-27 

internal, 3-26 
Stack structure, 

abnormal SST fault, 3-27 

data items on stack, 3-28 

internal SST fault, 3-26 
Status Control Block (SCB) , 

description, 4-19 

relationship of, with I/O 
control blocks, 2-6 

required field, 3-7 

role of, in I/O data 



Status Control Block (SCB) 
(Cont.) 

structure, 2-20 
Status Control Block (SCB) 
field, 
S.BMSK, 4-20 
S.BMSV, 4-20 
S.CON, 3-7, 4-22 
S.CSR, 3-7, 4-22 
S.CTM, 4-21 
S.FRK, 3-7, 4-23 
S.ITM, 3-7, 4-21 to 4-22 
S.LHD, 3-7 to 3-8, 4-2, 4-20 
S.MPR, 3-7, 4-23, B-l to B-2 
S.PKT, 4-23 
S.PRI, 3-7, 4-21 
S.RCNT, 4-20 
S.ROFF, 4-20 
S.STS, 3-7, 4-22 
S.VCT, 3-7, 4-21 
$STKDP pointer, 

use of, in fault tracing, 
3-23 
$STMAP routine, 5-26, 
B-2 to B-3 
use of, to obtain UMRs, B-l 
$STMP1 routine, 5-27, 
B-2 to B-3 
use of, to obtain UMRs, B-l 
$STPCT routine, 

use of, by ACP, D-7 
$SWSTK routine, 5-28 
Symbolic offsets, 

for system data structures, 
C-l 
SYSCM, 

See System common 
SYSTB file, 

creation of, by SYSGEN, 3-1 
System common (SYSCM) , 

use of, in fault isolation, 
3-23 
System common (SYSCM) pointer, 
$CRAVL, 3-28 
$HEADR, 3-24, 3-27 
$PKAVL, 3-28 
$STKDP, 3-23, 3-27 
$TKTCB, 3-24, 3-27 
System data structure macro 
definition, C-l 
ABODF$, C-3 
CLKDF$, C-4 
DCBDF$, C-6 
EPKDF$, C-7 
F11DF$, C-14 
HDRDF$, C-l 9 
HWDDF$, C-21 
ITBDF$, C-24 
LCBDF$, C-25 
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System data structure macro 

(Cont.) 

MTADF$, C-26 

PCBDF$, C-30 

PKTDF$, C-32 

SCBDF$, C-37 

TCBDF$, C-39 

UCBDF$, C-42 
System generation, 

incorporating driver, 3-1 
System state register 
convention, 5-1 



Task header, 

mapped system, 3-25 

role of, in I/O data 
structure, 2-19 

unmapped system, 3-24 
$TKTCB pointer, 

use of, in fault tracing, 
3-24 
Transfer function, 

processing, 4-13 
TTDRV, 

LOA special case, 3-5 



UCB, 

See Unit Control Block 
UNIBUS Mapping Register, 

static allocation of, during 
system generation, B-4 
Unit Control Block (UCB) , 

description, 4-23 

figure, 4-26 

negative offset, 4-9 

relationship of, with I/O 
control blocks, 2-6 

required field, 3-7 

role of, in I/O data 
structure, 2-20 

with ACP, D-9 
Unit Control Block (UCB) field, 

U.ATT, 3-7, 4-31 

U.BUF, 4-31 

U.CLI, 4-25 

U.CNT, 4-32, B-l 



U.CTL, 2-9, 3-7, 4-10, 4-27 

U.CW1, 3-7, 4-29 

U.CW2, 3-7, 4-30 

U.CW3, 3-7, 4-30 

U.CW4, 3-7, 4-31 

U.DCB, 3-6 to 3-8, 4-9, 4-27 

U.ERHC, 4-25 

U.ERHL, 4-24 

U.ERSC, 4-24 

U.ERSL, 4-24 

U.IOC, 4-24 

U.LUIC, 4<-25 

U.MUP, 4-25 

U.OWN, 4-27 

U.RED, 3-7 to 3-8, 4-27 

U.SCB, 3-7 to 3-8, 4-31 

U.ST2, 3-7, 4-29 

U.STS, 3-7, 4-28 

U.UNIT, 3-7, 4-29 
UNL command, 

unloading driver, 3-2 
USRTB file, 

content, 3-12 
$USRTB label, 3-13 



Volume Control Block' (VCB) , 
role of, in I/O data 
structure, 2-20 



Window Block (WB) , 
role of, in I/O data 

structure, 2-19 to 2-20 



XDT, 

See Executive Debugging Tool 
$xxDAT label, 3-9 
$xxEND label, 3-9 
$xxINP symbol, 3-5 
$xxINT symbol, 3-5 
$xxOUT symbol, 3-5 
$xxTBL label, 

on driver dispatch table 
(DDT), 4-10 
$xxTBL symbol, 3-5 
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